|
|
Subscribe / Log in / New account

disabling HSTS

disabling HSTS

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

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.


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds