[tor-mirrors] HSTS for a tor mirror

Dave Warren dw at thedave.ca
Wed Jan 3 03:26:41 UTC 2018


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.


More information about the tor-mirrors mailing list