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

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

On Wed, Aug 08, 2018 at 04:27:33PM +0000, Need Secure Mail wrote:
> On August 8, 2018 1:57 PM, Matthew Finkel <matthew.finkel@xxxxxxxxx> wrote:
> 
> > 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
> 
> Thanks, I was already quite familiar with the RFC. I know its rationale.
> 
> But it is an absolute rule that *I* get the final word on what my machine
> does. That is why I run open-source software, after all. I understand that
> most users essentially must be protected from their own bad decisions when
> faced with clickthrough warnings. I have read the pertinent research. It's
> fine that the easy-clickthrough GUI button is removed by HSTS. However,
> if *I* desire to "completely defeat the purpose of HSTS", then I shall
> do so, and my user-agent shall obey me. I understand exactly how HSTS
> works, and I know the implications of overriding it.

Please consider opening a bug with Mozilla for this.

> 
> >> 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.
> 
> Although I did not check the browser's preload list, I have observed
> this on a relatively obscure domain very unlikely to be on it...

Full list (for latest stable Tor Browser):
https://gitweb.torproject.org/tor-browser.git/plain/security/manager/ssl/nsSTSPreloadList.inc?h=tor-browser-52.9.0esr-7.5-2

I don't have a good explanation for why you experienced this.

[snip]

> >> 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).
> 
> Key phrase: "for some definitions of prevent".
> 
> Inductive reasoning: For a site not in the STS preload list and never
> before visited, the only means for the user-agent to know about STS is
> to receive an HTTP response header. The only means to receive an HTTP
> response header, is to send HTTP request headers. Assume that the browser
> does not make an HTTP request. How does it know that the site uses STS?

Correct. HSTS is a TOFU protocol, and it only takes effect on the
second connection. From what I see in the Firefox code, the HSTS value
is only cached after the HTTP response header is parsed. The next time
the website is requested, Firefox checks the cache for a STS entry and
forces TLS if an entry exists.

Unless the browser includes the domain in the STS preload list, you
shouldn't experience a problem loading a broken-TLS-configured website
until the second request. But, maybe I missed something.
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk