On Wed, Aug 08, 2018 at 10:59:23AM +0000, Need Secure Mail wrote: > On August 7, 2018 11:14 PM, nusenu <nusenu-li...@riseup.net> wrote: > >> did you notice the non-HSTS/HSTS distinction when trying to add an > >> exception? > > On August 8, 2018 1:51 AM, grarpamp <grarp...@gmail.com> wrote: > > If there is, would have to look closer, thx. > > The following is to help searchers who rammed their heads into this > problem, as I did when accessing clearnet version of a rather popular > .onion (LE cert). > > Firefox/Tor Browser disallows adding an exception. The "add an exception" > button does not even appear! It gives the error message: > > "This site uses HTTP Strict Transport Security (HSTS) to specify that > Tor Browser may only connect to it securely. As a result, it is not > possible to add an exception for this certificate."
Right. This is the recommendation in the RFC [0]. It would be counter-productive if the webserver informed the browser that the website should only be loaded over a secure connection, and then the user was given the option of ignore that. That would completely defeat the purpose of HSTS. [0] https://tools.ietf.org/html/rfc6797#page-30 Section 12.1 [snip] > ---- > > Topic drift observation: > > This error made me realize that Tor Browser/Firefox must load at least the > response HTTP headers before displaying the certificate error message. I > did not realize this! I reasonably assumed that it had simply refused to > complete the TLS handshake. No TLS connection, no way to know about HSTS. Why? There are three(?) options here: 1) The domain is preloaded in the browser's STS list, so it knows ahead of time if that site should only use TLS or not. If it is in the preloaded list, then the browser establishes a TLS connection as the first step. If this fails, then none of the HTTP Request was leaked. If the TLS connection fails, then the user is shown an error page and cannot add an exception. 2) The domain is not in the preloaded list, so the browser learns about the website setting HSTS on its first successful TLS connection and HTTP request. This would potentially leak the user's entire request to a MITM but this (HSTS) would not detect a MITM either. The MITM (or malicious endpoint) would only be detected if they served an invalid certificate chain for the domain name. The HSTS header would only prevent the user from loading the website over an insecure HTTP connection in the future. 3) The user previously loaded the site and the browser cached a STS value for that domain. If the user tries visiting the website again, except this time they request an insecure connection, then the browser will rewrite the URI so it uses TLS port 443 (by default), and then it will initiate the TLS connection. There isn't any information leaked before the TLS handshake. Furthermore, if the server and browser cannot negotiate a valid TLS connection (because the certificate-chain is invalid, or the ciphersuites don't intersect), then the user is presented with an error message which they cannot override and add an exception (as you experienced). > > Scary. How much does Tor Browser actually load over an *unauthenticated* > connection? Most importantly, I am curious, does it leak the request > URI path (including query string parameters) this way? Or does it do > something like a `HEAD /` to specifically check for HSTS? No request > headers, no response headers, no way to know about HSTS. Spies running > sslstrip may be interested in that. No? This was one of the main goals of HSTS. It should prevent SSL stripping (for some definitions of prevent). I'm also not sure if you're referring to public key pinning, as well. Where the website can specify the exact hash of its public key in the HTTP headers. That is another topic, and that relies on Trust-On-First-Use, as well. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
