* Dave Warren <dw@thedave.ca> [2018-01-02 03:44 +0100]:

On 2017-12-31 08:31, Valentin Brandl wrote: I took this as a sign that I should remove my (default) redirect and HSTS for my mirror, allowing users to make their own choice. I still offer HTTPS with a valid certificate.

Your mileage may vary.

I decided to serve the mirror both via HTTP and HTTPS and include the HSTS (and also HPKP) headers in HTTPS requests but I won't put the domain into the HSTS preload list since that might force some non-technical users to the HTTPS version, which might be blocked. -- greetings Valentin Brandl

On 2018-01-02 05:39, Alain Wolf wrote:

So I figured it might be left as an exercise to the user to disable HSTS in his browser. Because if he lives or works behind such a proxy he will be barred from more then half of the worlds websites by the end of the year.

It also occurs to me that a user who is blocked from using HTTPS won't see the HSTS header delivered over HTTPS at all. Therefore as long as you don't force a redirect from HTTP to HTTPS for your mirror's hostname, the mirror should more or less "just work" even for users who 1) honor HSTS, and 2) have previously visited your bare domain or www. Users who can't use HTTPS will likely (hopefully?) be aware of how to disable HSTS, although it would be a shame if the technical knowledge to reconfigure one's existing browser became a requirement to download Tor. Either way, I doubt a couple of mirrors make much difference, but I feel it's worth discussing the relative merits as though all mirrors were to make changes.

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.