[WIP] do-not-merge -- fix/bind-nitro-attestation-to-sessions #6
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refs/pull/6/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
⚠️ Old checkpoint PR, new work for merging is in #7
localhost/127.0.0.1CORS + stale-worker recovery)/e2p/from passthroughtests
eval-attestationfeature +steve-evalbinary serving signed synthetic Nitro evidence, Docker fixture, browser demo, and Playwright suite./scripts/test-e2e.sh(full E2E) or./scripts/test-e2e.sh up→ http://127.0.0.1:3000 (manual demo)what it does vs v1 of steve
v1: Nitro evidence → process-lifetime Ed25519 key → signed ephemeral X25519 exchange → one AES key
This PR: Nitro evidence → exact X25519 transcript + derived-secret binder → directional traffic keys
Added a local signed-synthetic E2E harness and debug UI for STEVE v2.
Included
eval-attestationfeature andsteve-evalbinary using signed Nitro-shaped evidence with an evaluation trust root.Synthetic evidence exercises the protocol and verifier logic, but does not prove Nitro hardware isolation or approved-PCR policy.
Run it
Current validation: 12 Playwright E2E, 42 JavaScript, and 19 Rust tests.
Careful pre-merge review found two issues I think should be fixed before merge:
STEVE_CORS_ORIGINS="*"is accepted for the E2P API (crates/steve/src/lib.rsaroundcors_layer). With wildcard CORS, any browser origin can run the SDK, establish an E2P session, and send encrypted requests that STEVE forwards to the protected upstream. Since the decrypted envelope controls method/path/headers, this effectively authorizes arbitrary web origins to use STEVE as a cross-origin gateway to the upstream. I think production should require an explicit allow-list of authorized application origins, or wildcard should be gated to an explicit dev/eval mode.The service worker default passthrough list includes
/, andisPassthrough()only checks the pathname (steve-js-sdk/src/enclave-sw.js). That means any controlled same-origin request to/bypasses E2P, including non-bootstrap requests such asPOST /with a sensitive body. The bootstrap exception should be method/mode-aware (for example only top-level/documentGET /) or/should not be a default passthrough path.Security review notes from a pass over PR #6. I think the main things to address/check are:
Workload identity is not enforced yet. The browser verifies a valid AWS Nitro attestation and the v2 session binding, but I don't see an expected PCR/module/image policy being checked (
expectedPcrPolicy: 'not-checked'). A malicious service in some other valid Nitro enclave could bind its own session and pass unless clients also pin the intended STEVE workload identity. I'd fail closed on an expected PCR/manifest/verifier-key policy for production.Upstream redirects can escape the origin guard.
upstream_url()constrains the initial path to the configured upstream, but the shared reqwest client uses default redirect handling. If the upstream app has an open redirect, STEVE can be made to fetch link-local/internal/cross-origin URLs. I'd setredirect(Policy::none())or manually follow only same-origin redirects.Upstream responses are read fully with no explicit timeout/size cap. Both protected and plaintext forwarding call
.bytes().await, and the reqwest client has no timeout. A large/slow/streaming upstream response can tie up tasks or enclave memory. I'd add timeouts and stream with a max response size.Service-worker config is persistently mutable by any controlled same-origin page.
configurecan changeenclaveOrigin, passthrough/exclude rules, timeouts, and diagnostics, and it is persisted. This may be acceptable if same-origin JS is fully trusted, but for shared origins/user-content/partial-XSS it lets a lower-privilege page persistently weaken protection. Consider narrowing scope or authenticating privileged SW commands.Production container build should probably use
--lockedand an explicit package/bin so reviewedCargo.lockis authoritative.Eval-only Rust artifacts still appear in
cargo package --list(src/bin/steve-eval.rs,src/eval_attestation.rs). Not a container blocker with default features off, but worth tightening if source/Cargo release surfaces are meant to exclude eval material too.I ran
cargo test -p steve --all-targets --all-features(21 passed),NODE_OPTIONS=--experimental-global-webcrypto npm --prefix steve-js-sdk test(44 passed), and./scripts/test-production-exclusions.sh(passed).Will review the last comments on #7, let's use #7 as this one is just a linear checkpoint included in 7
This PR is included in #7, closing
Pull request closed