I absolutely care. About how absolutely cursed HSTS is as a concept. It's basically the EME of TLS.
The idea that they put it right in the specification that browsers were prohibited from allowing users to bypass it, even if they know what they're doing, fully moved browsers out of the "user agent" category.
Is that a Chrome thing? I'm a Firefox user, generally. But my understanding is if the browser allows any sort of bypass it is not compliant with the spec.
Yes, I have had this discussion with Google staff. Their opinion is that "thisisunsafe" is not really a bypass even though that's obviously exactly what it is and exactly how it is used.
Historically there have been several phrases used, with changes once every few years, and the weak argument is that people who go to the bother of learning each new phrase, plus the fact the phrase tells you it's a bad idea (one of them literally) would bypass this anyway, but well... would they?
Human psychology doesn't work that way. People get into the habit of typing whatever the magic phrase is and then they're astonished that it was a bad idea even though it just said so. You can't build effective security systems on such foundations.
This is because we cry wolf too many times. When was the last time you cared about the SSH message REMOTE HOST IDENTIFICATION HAS CHANGED DANGER DANGER SPOOKY SCARY? I bet never because 100 times out of 100 that message is because of a misconfiguration on the remote host or someone termed the instance and uses the autogenerated keys.
Same with TLS errors. I have never once encountered a single instance of someone trying to intercept my connection but I’ve encountered hundreds of misconfigured but otherwise perfectly functional servers if you just ignore the errors.
You can’t really blame users when you hide literally all the details that would allow them to make an informed decision about whether they should hit “It’s Fine False Alarm” or “Oh Shit Got Em” and then be surprised when people hit the false alarm button without thinking when it’s always a damn false alarm.
We would do so much better if we had screens like, “Hey the cert the server sent is otherwise valid but expired 5 minutes ago, is that cool?” or “The server sent a certificate for bloop.domain” but you connected to “blorp.domain” with options like “Seems Sus”, “My b it was a typo” and “Damn, autocorrect gottem.”
Like we have absolutely zero reasonable sense of security and risk as anything other than perfectly secure and defcon 69.
This is where I fundamentally disagree with a lot of security folks: if the the user is really, truly, absolutely sure that they want to shoot themselves in the foot, you should let them. It's their life to live.
Only Mother Nature gets to make rules nobody can disobey, so of course the user can shoot themselves in the foot. But, we needn't provide them with the gun, or the bullets.
Yeah, I have no issue with a site indicating it only wants to talk over HTTPS. But to disable my ability to proceed even if I know what's going on with the site in question is constantly irritating.
I also dislike HSTS. I modified the .so file so that it does not recognize the Strict-Transport-Security header. (There are many other features that are also bad, but HSTS is especially bad.)
The browser MUST allow the end user to override EVERYTHING (and assume that you know what you are doing, instead of trying to do things for you differently than what you did), and then it will be good.
They put that requirement in there because HSTS is pointless without it. The website is literally saying "we will always (w/ expiration) have valid TLS, if we don't that's a problem". Allowing users to bypass it allows criminals to go "oh we're having problems with the cert, just type 'badidea' and click yes to continue to be hacked".
A user agent must work for the user, not the server. Obeying the server over the user's intent is malicious design.
And if that makes it pointless, then just remove it entirely. Believe it or not, I've never seen a cert error in the wild that wasn't an expiration of a valid cert or a misconfiguration.
The boogeyman of MITM attacks which PKI certs protect from is used to justify a lot of terrible changes to the web that aren't reflected by reality: In most cases they're just going to hack the real server and serve malicious content from your valid certificate anyways. Or they'll trick someone into giving their credentials to bonkofamerica.com because people are easy to fool. Why MITM Amazon when people will happily treat an order email sent from a Gmail account as legitimate?
> I've never seen a cert error in the wild that wasn't an expiration of a valid cert or a misconfiguration.
I have. Usually caused by a captive portal.
> The boogeyman of MITM attacks which PKI certs protect from is used to justify a lot of terrible changes to the web that aren't reflected by reality.
The move to use HTTPS everywhere was started in response to packet sniffing tools like Firesheep. That’s not a boogeyman; it’s a proof of concept that works in realistic scenarios.
> Why MITM Amazon when people will happily treat an order email sent from a Gmail account as legitimate?
>Allowing users to bypass it allows criminals to go "oh we're having problems with the cert, just type 'badidea' and click yes to continue to be hacked".
Are you using this as an example of how HSTS is helping users now? Because Chrome allows you to type 'thisisunsafe' and you'll get through the warning, regardless of HSTS.
No. If I click an http:// link, I want that link to be upgraded automatically to https:// if possible so that MITMs can't read or modify the request or response. I would still get that benefit if the browser made it easy to click through certificate warnings.
If you're being MITM'd then you'll get a certificate warning. If it's easy to click through those then it's easy for MITMs to read or modify the request.
Did I say I want the browser to let me click through it?
However, in general I think the browser preventing the user from doing something the user wants is a bit offputting. The browser is a "user agent". It should act on behalf of the user. If the user wants it to do something, it should do that. This case is tricky, because sometimes what the user really wants is not what the user is asking the user agent to do. It's an xy problem. I think Chrome's current behavior strikes a nice balance.
The idea that they put it right in the specification that browsers were prohibited from allowing users to bypass it, even if they know what they're doing, fully moved browsers out of the "user agent" category.