Closed Bug 698362 Opened 10 years ago Closed 5 years ago
Decide what to do regarding Alternate-Protocol vs redirects
+++ 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.
alt-svc is on standards track
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.