-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Other HTTPS Redirect Methods #177
Comments
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: