From MozillaWiki
Jump to: navigation, search

tems to be reviewed: SPDY Implementation

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


  • 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