Tor exit node operator arrested in Russia (TorServers.net blog)

The site's administrator specifically doesn't want you reading their site without HTTPS, that's the purpose of the HSTS setting. A web browser seems like exactly the right place to put that behaviour choice, if you want to subvert it through technical means you can, as shown, but there's no reason it would be the default.

Now, doubtless you'll protest that clicking through a warning isn't "the default", but alas because of a human cognitive defect it is. Anything that gets in the way of the task is dismissed. This isn't something special about the web, or computers, it happens in the real world too, most of those "low bridge" crashes happen that way, the driver is intellectually able to process the fact that their vehicle is too tall for the bridge, but their plan says they're going to drive under the bridge, only hitting the bridge will finally undo that plan.

The overarching philosophy is also important to a browser as opposed to something like curl that just fetches a single resource. What happens if an image link leads to an HSTS site with a defective certificate? Does the image load anyway? How is it indicated to you, the end user, that the image isn't actually trusted after all despite it seeming to be from an HTTPS URL? What if instead of an image it's Javascript? What if it's an Ajax endpoint?

In practice humans aren't interested in taking on the tremendous work implied by letting them, as you would, take the decision. So, they're just going to click "Yes / ignore / I don't care / fuck it, in for a penny in for a pound" and in practice the browser's policy becomes "We don't actually have security, we decided users would prefer to go without". So long as there are only a tiny minority opting out this even looks superficially safe - it's not worth targeting a few thousand Pale Moon users.

Also, did you know that when you override a cert error, you allow that cert for any SAN in it, not just the one you are connecting to? So if that cert is for www.securityblog.example.com and also www.paypal.com, you just allowed them to MITM you for paypal.com. This is more of a risk for self-signed than for expired, but I bet you didn't know it, nevertheless.

Overriding SSL cert errors, particularly with the permanent flag checked, is a _bad_ idea.

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.

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.