Skip to content
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

Open
RealityRipple opened this issue Jun 16, 2019 · 2 comments
Open

Other HTTPS Redirect Methods #177

RealityRipple opened this issue Jun 16, 2019 · 2 comments

Comments

@RealityRipple
Copy link

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
Copy link
Collaborator

nharper commented Jun 17, 2019

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants