698362 - Decide what to do regarding Alternate-Protocol vs redirects

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #528288 +++

During the security review for SPDY it was brought up that Alternate-Protocol is very similar to a redirect, has the same (or at least very similar) security properties to a redirect, and possibly we should push for standardization of a redirect-based approach instead of the Alternate-Protocol based approach, to avoid adding complexity.

One advantage of Alternate-Protocol is that it (IIRC) allows the server to return a useful response while redirecting *future* requests to the HTTPS (SPDY) site. However, I am not sure how useful or good this is, because that one resource would not be usefully cacheable (since we would rewrite all future requests for it from HTTP:// to HTTPS://). Also, we have to be sure that we don't cause that one non-TLS-protected resource to look like it is TLS-protected.

Also, since the Alternate-Protocol header isn't protected by TLS, it seems like it would be useful to have a counterpart to it that *is* protected by TLS, that indicates "this is the HTTPS version of the corresponding HTTP resource", similar to how HSTS works. However, such a feature might not be so useful, since it would protect against an attack where the attacker wants to redirect you from an insecure connection to a secure connection on the same server, and usually attackers would prefer to redirect victims in the opposite direction (HTTPS -> HTTP), and an attacker could just rewrite the response to be an actual 30x redirect to the target URL anyway. 

That said, such a HSTS-like TLS-protected header has been discussed by Mozilla's security team for other uses already, to help migrate sites from mixed content subresources to HTTPS subresources.

Comment 1

[Patrick McManus [:mcmanus]]

alt-svc is on standards track