On Wed, Aug 08, 2018 at 04:27:33PM +0000, Need Secure Mail wrote: > On August 8, 2018 1:57 PM, Matthew Finkel <matthew.fin...@gmail.com> 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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
