Browsers are increasingly willing to say no to users over HTTPS issues

January 22, 2016

One of the quiet sea changes that underpins a significant increase in the security of the modern HTTPS web is that browsers are increasingly willing to say no to users. I happen to think that this is a big change, but it's one that didn't really strike me until recently.

There was a time when the fundamental imperative of browsers was that if the user insisted enough, they could go ahead with operations that the browser was pretty sure were a bad idea; attempts to change this back in the days were met by strong pushback. The inevitable result of those decisions was that attackers who wanted to MITM people's HTTPS connections to places like Facebook could often just present a self-signed certificate generated by their MITM interceptor system and have most people accept it. When attackers couldn't do that, they could often force downgrades to unencrypted HTTP (or just stop upgrades from an initial HTTP connection to a HTTPS one); again, these mostly got accepted. People wrote impassioned security advice that boiled down to 'please don't do that' and tweaked and overhauled security warning UIs, but all of it was ultimately somewhat futile because most users just didn't care. They wanted their Facebook, thanks, and they didn't really care (or even read) beyond that.

(There are any number of rational reasons for this, including the often very high rate of false positives in security alerts.)

Over the past few years that has changed. Yes, most of the changes are opt-in on the part of websites, using things like HSTS and HPKP, but the really big sea changes is browsers mostly do not let users override the website settings. Instead, browsers are now willing to hard-fail connections because of HSTS or HPKP settings even if this angers users because they can't get to Facebook or wherever. Yes, browsers have a defense in that the site told them to do this, but in the past I'm not sure this would have cut enough ice to be accepted by browser developers.

(In the process browsers are now willing to let sites commit HSTS or HPKP suicide, with very little chance to recover from eg key loss or inability to offer HTTPS for a while for some reason.)

Obviously related to this is the increasing willingness of browsers to refuse SSL ciphers and so on that are now considered too weak, again pretty much without user overrides. Given that browsers used to accept pretty much any old SSL crap in the name of backwards compatibility, this is itself a welcome change.

(Despite my past views, I think that browsers are making the right overall choice here even if it's probably going to cause me heartburn sooner or later. I previously threw other people under the HTTPS bus in the name of the greater good, so it's only fair that I get thrown under it too sooner or later, and it behooves me to take it with good grace.)


Comments on this page:

Snowden I guess.

By cks at 2016-01-23 16:38:00:

While Snowden undoubtedly didn't hurt, I think that browsers were moving steadily in this direction even before then (eg, even back in 2008 Firefox was trying to get in the way of people accepting self-signed certificates). My guess is that a good part of it is that browser developers started off fundamentally trusting users to make the right choices, then over time came to understand and accept that this didn't work. Offering choices to users had the practical effect of making them less secure; it wasn't helping them and was often hurting.

I suspect that part of this was a rising awareness among browser people that the Internet was being used by ordinary people for really important stuff. In the days of 'the Internet is for cat pictures', maybe overall security is not a big deal to anyone except banks. But once activists started using it to organize things against oppressive regimes, well, your browser letting the authorities intercept their Facebook/etc chats could have really dire consequences.

(I believe that Facebook was moving more and more towards HTTPS and HTTPS only even before the Snowden revelations, for example.)

To put it another way: I think that browser security people have increasingly shifted from a purely technical engineering persective to one where they start by evaluating outcomes. The old attitude was the mathematical security one of 'we gave you all the necessary tools for security, if you screwed it up it's not our fault'; the new one is 'let's make it so that as many people as possible do wind up being secure'. Which is a good shift to have happen, because practical outcomes are what matter.

(This is a drum that I've been beating for a long time, so I'm biased in how I interpret what I see in front of me. Apply salt to taste.)

Yes. But the older trend seems to me to have been more of a pure usability/affordances awareness for the design of error screens, putting overrides behind hoops that would effectively exclude most non-technical users. This contemporary will to confront users with hard failures and no overrides and just “too bad for you” feels different in quality to me, even if it’s quantitatively not too far away, and my impression is that it was not until Snowden that this attitude gained influence. Maybe there was not a step change in attitude so much as a change in the collective mood behind it? What do you feel happened?

By cks at 2016-01-24 18:52:13:

I honestly don't know enough about the timing and how the various browser people acted to have any well-informed opinions on what really happened and drove the changes. It's certainly possible that Snowden's revelations lit a fire under people and made things possible that had been ruled out before, or that those revelations led to other ones (eg Hacking Team and the pervasiveness of state-level attacks) that similarly influenced browser people.

Written on 22 January 2016.
« Memory-safe languages and reading very sensitive files
Hostile HTTPS interception on the modern web is now increasingly costly and risky »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Fri Jan 22 22:37:24 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.