It all started pretty well, with the announcement by Mozilla at the end of last month that the Firefox web browser would make the Internet a safer place by encrypting everything. That's everything, even those connections where the servers don't even support the HTTPS protocol. Developers of the Firefox browser have moved one step closer to an Internet that encrypts all the world's traffic with a new feature that can cryptographically protect connections even when servers don't support HTTPS. The 'Opportunistic Encryption' (OE) feature essentially acts as a bridge between non-compliant plaintext HTTP connections and fully compliant and secure HTTPS ones. Firefox 37 made OE active by default, supposedly protecting sites that hadn't bothered with going through the digital certificate authority process, or which don't fully encrypt everything courtesy of embedded plaintext third party content requirements such as adverts for example.
At the time, Mozilla networking engineer stated "OE provides unauthenticated encryption over TLS for data that would otherwise be carried via clear text. This creates some confidentiality in the face of passive eavesdropping, and also provides you much better integrity protection for your data than raw TCP does when dealing with random network noise. The server setup for it is trivial. Only HTTPS protects you from active man in the middle attackers. But if you have long tail of legacy content that you cannot yet get migrated to HTTPS, commonly due to mixed-content rules and interactions with third parties, OE provides a mechanism for an encrypted transport of http:// data. That's a strict improvement over the cleartext alternative."
All of which was great, and hard to argue with. Mozilla had done a good thing in helping make the Internet a little more secure through enabling the OE functionality in Firefox. And then, a few days later, this happened: Mozilla Foundation Security Advisory 2015-44. Entitled 'Certificate verification bypass through the HTTP/2 Alt-Svc header' it detailed a critical vulnerability in the Firefox implementation of the HTTP Alternative Services specification. Specifically, this vulnerability meant that if an Alt-Svc header is specified in the HTTP/2 response, SSL certificate verification can be bypassed for the specified alternate server. In other words, any warnings of an invalid SSL certificate wouldn't get displayed so the attacker could then impersonate another site through a man-in-the-middle attack: precisely what OE is meant to prevent.
Russ Spitler, VP of product strategy for security outfit AlienVault, explains what went wrong. "The root of this issue is the fact that our current system has rather tightly coupled authentication with encryption. To break that down a little further authentication is knowing who you are talking to, encryption is knowing nobody else is listening. The state of the world right now is that if you can’t confirm who you are talking to, you cannot ensure that no one else is listening. Opportunistic encryption provided a path to ensure nobody is listening without necessarily authenticating who you are talking to. This bug allowed attackers to exploit opportunistic encryption (which does not authenticate who you are talking to) so that users believe they have authenticated the other end (by presenting a certificate to the browser). This allows an attacker to establish a connection with a user that appears to originate from a trusted entity (such as Google), but is controlled by the attacker."
Is Mozilla to be blamed for rolling the OE functionality out without due diligence? That's a tough one. The simple and obvious answer is yes, after all the proof of this pudding has been eaten very publicly indeed. Yet, as Spitler says "we have dealt with issues in this system for years and years, getting this done correctly and without bugs is a process that will take decades - consider how long some of the recent OpenSSL bugs existed in code before discovery." Personally, I am very disappointed that yet another great move forward in security terms has ended up taking two steps backwards because of what can only really be seen as sloppy design and iteration, with a poor testing procedure in the run up to implementation. Without proper review processes and rigorous testing these kind of vulnerabilities are always going to be likely to slip through into production, and that dents public confidence both in the product itself, the brand behind it and most importantly as far as I am concerned the forward thinking technology that has been badly implemented.
Perhaps even more worrying, as Spitler points out, is why Mozilla felt the need to reinvent the encryption wheel in the first place. "As for opportunistic encryption: why build a new system when there is one that already exists?" he asks, continuing "Projects like ‘Let's Encrypt’ are making it easy to achieve the same goals as above without reinventing a new system. While the goal is noble, rebuilding encryptions systems should be done only when absolutely necessary, not when there are viable improvements to existing standards."