Security/Reviews/Firefox10/SPDY

From MozillaWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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).
  • 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