disabling HSTS [LWN.net]

disabling HSTS

Posted Apr 18, 2017 13:22 UTC (Tue) by bandrami (guest, #94229)
In reply to: disabling HSTS by tialaramex
Parent article: Tor exit node operator arrested in Russia (TorServers.net blog)

Funny, I don't know of a single browser that complains about a plaintext connection, despite the fact that it's strictly worse than an HTTPS connection with a problematic certificate. Kind of makes the whole certificate verification paranoia seem like so much theater.

Seriously, this seems so obvious: there are two questions that TLS is trying to answer at once. I want to know

A) is the transport between me and the other party secure? and sometimes
B) is the other party who he or she claims to be?

For most traffic (where even a verified A isn't particularly trusted), A is the much more important question, and hand-wringing about B has prevented widespread adoption of simple techniques to solve A. Establish a secure channel, and we can then use that to negotiate authenticity.

to post comments

disabling HSTS

Posted Apr 18, 2017 14:02 UTC (Tue) by tialaramex (subscriber, #21167) [Link]

In this case, torservers.net is HSTS pre-loaded. So if you try typing the HTTP version of the URL into a halfway modern browser it'll just turn into the HTTPS version. It won't complain, it just won't let you access the HTTP URLs at all.

In a current (late 2016, 2017) browser HTTP sites are affirmatively marked insecure if they seem to have content that you'd expect to be secured, such as a password dialog (really, you want asterisks on the screen, then you're going to send it plaintext over the Internet..?). In a modern (2015 onwards) browser new features don't work for HTTP at all, location services, integrated video conferencing, all that stuff is gated on HTTPS

Eventually (maybe 10 years from here) HTTP sites will all be marked affirmatively insecure, so yes, the browser will "complain". In hindsight this is how things should have worked from the outset, but I've met Tim and he's not exactly the sort of person to fully chase things through before putting them live, so by the time his Web was visible to the world it was too late.

Your A / B observation is very old, and we accepted the same rationale for SMTP (see below) but notice that A without B gives you nothing whatsoever in the fact of an active adversary. Now, many years ago people might have argued that active adversaries are extremely rare, maybe they don't even exist. But then Google & co inadvertently discovered that they not only exist, they're so common they think this is their network and they will fight very hard to sabotage it if given the opportunity. Such adversaries do not wish their existence to be widely known, if you've ever wondered why Google is so enthusiastic about transparency, that's why. Creatures that fear the light are not dangerous - so long as you stay out of the shade.

Now, for SMTP we were stuck with a problem. Like HTTP, SMTP is plaintext by default and there was a huge installed base of systems that only grok plaintext SMTP. To deploy anything at all it needed to seamlessly interoperate, otherwise you've got a flag day for email and that's not happening. So for SMTP we have "opportunistic encryption" where most clients will ignore the poor quality of certificates and encryption settings out there, because anything is better than nothing. But the result is pretty poor, an active adversary can snoop all the email pretty effectively, we know that in some countries this is happening today - and even a passive adversary can snoop a lot of email, a lot of the time. We have no idea how common that is. But it's a start, the ambition is to some day tighten things up, as happened previously for the Web PKI itself.

disabling HSTS

Posted Apr 18, 2017 14:21 UTC (Tue) by cesarb (subscriber, #6266) [Link]

> Seriously, this seems so obvious: there are two questions that TLS is trying to answer at once. I want to know
>
> A) is the transport between me and the other party secure? and sometimes
> B) is the other party who he or she claims to be?
>
> For most traffic (where even a verified A isn't particularly trusted), A is the much more important question, and hand-wringing about B has prevented widespread adoption of simple techniques to solve A. Establish a secure channel, and we can then use that to negotiate authenticity.

You can't solve A without solving B. If you don't know whether the other party is who they claim to be, you don't know whether you are talking to the other party or to an eavesdropper. That is, if Alice can't authenticate Bob, she can't know whether the connection is going A -> B or A -> E -> B, where Eve is talking to Alice as if she were Bob, and talking to Bob as if she were Alice, repeating (and possibly modifying) the messages between them.

> Funny, I don't know of a single browser that complains about a plaintext connection, despite the fact that it's strictly worse than an HTTPS connection with a problematic certificate. Kind of makes the whole certificate verification paranoia seem like so much theater.

I know of one: recent versions of Firefox complain about plaintext connections with password form fields. The reason for not complaining is historical (plaintext connections came first and are still very widespread), but that's slowly beginning to change. Also, once users start trusting the "https://" as the sign of a "safe" connection, it becomes important to warn or block the connection in case it's compromised.