[tor-mirrors] HSTS for a tor mirror
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
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
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