[tor-talk] HSTS forbids "Add an exception" (also, does request URI leak?)

[Matthew Finkel]

On Wed, Aug 08, 2018 at 10:59:23AM +0000, Need Secure Mail wrote:
> On August 7, 2018 11:14 PM, nusenu <nusenu-lists at 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 <grarpamp at 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.