Security/Reviews/Firefox10/SPDY
From MozillaWiki
tems to be reviewed: SPDY Implementation https://wiki.mozilla.org/Platform/Features/SPDY https://bugzilla.mozilla.org/show_bug.cgi?id=528288
Introduce Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- Wrapper around HTTP
- Always over SSL, uses 1 or 1.1
- Multiplexing: improves performance (like pipelining but without head-of-line blocking; like multiple connections (possibly with sharding) without the congestion-control mess)
Details of Feature
- Uses NPN (a portion of SSL) to negotiate between SPDY-over-SSL and HTTP-over-SSL
- That works great for sites that always use SSL, but there's also an "alternate-protocol" header (a kind of port redirection) that can be served over HTTP.
- We implement this as a non-persistent STS.
- If there's an error while trying to make that connection, the user might see an error page once, but the STS-like information is thrown away.
- Does the address bar for that error page show "http"??
- Shards are automatically collapsed (if the IP address matches and the certificate is good for both hostnames).
- That works great for sites that always use SSL, but there's also an "alternate-protocol" header (a kind of port redirection) that can be served over HTTP.
- Compression
- Headers are compressed, using an initial compression context (which is part of the spec).
- TLS-level compression is allowed, but there's no body compression in SPDY.
- "Accept-encoding: gzip" is assumed; the client doesn't need to say it.
What solutions/approaches were considered other than the proposed solution?
- none, implementation of protocol
Why was this solution chosen?
- Proposed standard from Google. (Google wrote the spec and may have submitted a draft to IETF.)
- The “Alternate-protocol” header is underspecified. (CDNs have been championing it; and it could help with migration.)
Any security threats already considered in the design and why?
- Always over SSL so we don't have to worry about proxies fucking things up.
Threat Brainstorming
- How does proxying interact with the shard-collapsing feature?
Connection sharing
- What's the significance of having multiple mutually-untrusting hostnames in the same connection? (As a workaround for SNI, many shared hosts and CDNs stuff a bunch of customers into a single cert!)
- Side-channel attacks: timing, number of bytes sent (especially combined with TLS-level compression).
Alternate-protocol
- Injecting the alternate-protocol header (MITM? Header injection flaws?)
- MITM attacker blocks the SSL connection after the user logs in.
- Address bar shows https (once a connection succeeds?), so SPDY users won't get thrown back to an insecure protocol :)
- What happens if a site uses alternate-protocol, and then once you're connected using SSL, says STS? Does the STS get persisted correctly at that point?
- What happens if an SSL site uses the alternate-protocol header?
- In the attempt-SSL-based-on-redirect case, do we send secure cookies only over SSL? Are the principals and origins and such correct?
- Looking at the code, looks like this is correct.
- Brian: the complexity of alternate-protocol bothers me. How about the client advertise support for SPDY and the server send a normal redirect?
- Brian: can we make alternate-protocol a little more persistent?
- Brian: we probably want to schedule a separate meeting to discuss alternate-protocol, perhaps once a spec materializes.
Conclusions / Action Items
- [bsterne] assign someone to fuzz the protocol (christoph)
- [bsmith/patrick] Alternate-Protocol spec and/or alternate solution
- server push isn't implemented by us yet; needs another discussion if/when implemented