On 2018-01-02 16:10, Heiko Richter wrote:
Hi all,
correctly configured HSTS enabled hosts don't serve their content over HTTP; they will *only* serve a 302 redirect to HTTPS. Therefor most of the discussion is entirely mute. Anybody banned from HTTPS will not be able to access the contect through HTTP because they will only receive a redirection to HTTPS. Any HSTS enabled server configured to serve content over HTTP is *broken*. Therefor the multiple suggestions on the list about making it a "user exercise" to disable HSTS on their browser are complete nonsense. Making content available on HTTP and therefor breaking HSTS is a administrative decision on the server side; there is nothing users can do to access a correctly configured HSTS enabled server if they are banned from using HTTPS. Anybody suggesting otherwise has missed the entire point of HSTS and should read up on the topic before writing about things they obviously do not understand.
This may be true from a spec perspective, but the real world is a little more complicated and does not always follow the specifications to the letter. These configurations can be utilized.
For example, HSTS on example.com might include subdomains and be properly implemented to redirect all HTTP requests to HTTPS. However, if bob.example.com doesn't redirect or serve HSTS headers (but does serve both HTTP and HTTPS), then one of two things will happen to a user hitting http://bob.example.com/:
1) Their browser knows about HSTS on example.com, and switches to https:// 2) Their browser does not know about HSTS on example.com and accesses http://
Since a user who has HTTPS completely blocked will not ever be able to learn that HSTS on example.com includes subdomains, they will be able to access http://bob.example.com/ directly. A user with HTTPS available may or may not have visited example.com, and therefore may or may not uses HSTS to redirect to HTTPS.
Obviously a user who periodically has HTTPS may fall into a category where they know of HSTS on example.com, but can't currently access the HTTPS version of bob.example.com. In this case, a user may choose to not store HSTS between sessions (a good practice if you are privacy sensitive, since HSTS can be used to identify a user even if cookies and other local storage are reset).
Being someone that travels a lot to third world countries and China I can tell you that blocking HTTPS completely is a thing of the past though. The section of the wiki recommending to disable HTTPS and/or enable HTTP is completely outdated and so is this discussion. Contrary to public oppinion the administrators of national firewalls know what they are doing and have information about the world around them. As more and more domains (espicially the big ones) are moving to HSTS and most browsers include preload lists most national firewalls have moved to transparent proxies with SSLBumping. Although the SSLBumping renders the encryption worthless people behind these firewalls have access to HTTPS and will be able to download from HSTS enabled mirrors.
Doesn't SSLBumping cause the enduser to see certificate errors? If so, modern browsers should prevent the user from overriding the certificate error for a HSTS enabled or preloaded site anyway. I admit I do not travel in such areas, so I'm unclear how this is handled or what techniques would be implemented in this situation.
The problem of today is not wehter or not users can access files though HTTPS; it's about wether or not a transparent proxy will recognize the tor installer for what it is and block its download.
This makes sense, and is a problem that will need a different solution.