2016-01-24
Hostile HTTPS interception on the modern web is now increasingly costly and risky
One of the things that HTTPS is vulnerable to is a state level actor armed with enough money that is willing (and able) to compromise a CA and get certificates issued for sites that they want to run a MITM attack against. This is nothing new; it is the core security problem of SSL on the web, namely that any of the hundreds of CAs that are trusted by your browser can generate a certificate for anyone.
Technically, that is still the case. All of the trusted CAs in the
world can still issue certificates for, say, gmail.com, and
quite a lot of browsers will trust those certificates. But not
Chrome. If you are an attacker and you try this against a Chrome
user, Chrome will try hard to scream bloody murder about this back
to Google (and refuse to go ahead). Then pretty soon Google's
security people will get to write another blog post and your nice
compromised CA will be lost to you (one way or another).
Chrome has been doing this for a while (this is part of how Google has gotten to write a number of blog posts about this sort of thing), but it is not alone. On the modern web, there are a steadily increasing number of things that are more or less automatically looking for and reporting bogus certificates and an increasing number of ways to block many of them from being useful to attack your site. On the one hand, many of the better things are not included in web browsers by default; on the other hand, many of the people that a state level actor is likely to be most interested in MITM'ing are exactly the sort of people who may install things like HTTPS Everywhere and enable its reporting features.
Based on what I've read from the security circles that I follow, the net effect of all of these changes is that mounting anything but an extremely carefully targeted MITM attack is almost certain to cost you the compromised CA you were able to exploit. Each compromised CA you have is good for exactly one attack, if that.
(See for example the Twitter conversation linked to here.)
This doesn't make HTTPS interception impossible, of course. CAs can still be compromised. But it means that no one is going to do this for anything except very high priority needs, which in practice makes us all safer by reducing how often it happens.
An important contributing factor to the increased chanciness of HTTPS interception is that browsers are increasingly willing to say no. There was a time when you could MITM a significant number of people with a plain old bogus certificate (no CA compromise required, just generate it on the fly in your MITM box). Those days are mostly over, especially for some popular sites, and increasingly even a real certificate from a compromised CA may not work due to things like HPKP.
2016-01-22
Browsers are increasingly willing to say no to users over HTTPS issues
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.)