search

chromium / hstspreload.org

:lock: Chromium's HSTS preload list submission website.
https://hstspreload.org
BSD 3-Clause "New" or "Revised" License
780 stars 91 forks source link

Other HTTPS Redirect Methods #177

Open RealityRipple opened 5 years ago

RealityRipple commented 5 years ago

While 301 and 308 header redirects are fine and all, they're not the only way to redirect a user. The Upgrade-Insecure-Requests header can be used for a more graceful redirect, or even a HTTPS-served JavaScript file on the HTTP version of the website (to verify that the browser can handle the server's setup), not to mention the classic refresh meta tag or inline JS. I realize it's a lot more work to implement some of these other methods, but they are legitimate ways of redirecting, and I can't see any reason why response codes are more secure than the other methods... the first request is going to be over HTTP regardless without this project. And UIR is basically designed exactly for this kind of redirect.

nharper commented 5 years ago

It's not clear to me what issue with this codebase you're trying to report.

301 (Moved Permanently) and 308 (Permanent Redirect) are the only permanent HTTP status codes for redirects. Upgrade-Insecure-Requests is sent by the client as a hint to the server that the client prefers resources served over HTTPS, but when a server receives that, it still needs to deliver something; a 3xx redirect (preferably 301 or 308) would be the most logical response.

Given that this issue is filed on the hstspreload.org project, I'm assuming that any server in question here is one that want HTTPS to be the authoritative scheme for its hostname. In that case, responding with a 301 or a 308 to HTTP requests sounds like the only logical thing to do: they identify where the resource is (at a location with an HTTPS scheme), and they signal that it's a permanent redirect. Using these instead of another redirect has the benefit that browsers that don't support HSTS can still cache the redirect for long periods of time.

RealityRipple commented 5 years ago

Any site that wants to retain compatibility with legacy systems (cough-internet-explorer-cough) needs to either handle classic TLS 1.0/1.1 or provide a more passive HTTPS upgrade methodology. A permanent redirect may be the desired solution, but it is by no means the only one.