Technical Perspective: Cleaning Up Flaws in TLS Implementations

One of the unfortunate facts about protocols is that as they get older and applied to more application scenarios—and TLS is used basically everywhere—they tend to gain weight. SSLv3 was not small to begin with: When it was designed it supported static RSA, ephemeral RSA, static Diffie-Hellman, ephemeral Diffie-Hellman, Fortezza, as well as a session resumption mode. Over the past 20 years or so, the IETF also added Elliptic Curve cipher suites, Kerberos, SRP, and 25 or so "extension" code points, ranging from Server Name Indication to token binding.

It is a truism in the security community that "complexity is the enemy of security" and the sheer surface area of TLS has historically made people uncomfortable, but what the miTLS team has shown is that all this stuff represents a real threat to user security. At a general level this is not surprising; as Steven Bellovin has said, "software has bugs and security software has security relevant bugs." What's new here? Two things: First, a general methodology for finding this kind of defect and a demonstration that it can find them on real systems. Second, the miTLS team has shown that having a large set of modes of various strengths was dangerous, even if your software is configured to favor the strong modes of operation or to only have strong modes—this was surprising (and bad) news to everyone who thought that they had protected themselves by disabling those weak modes!

What is the community doing about this problem?

It's a truism in the security community that "complexity is the enemy of security" and the sheer surface area of TLS has historically made people uncomfortable.

First, implementors are moving rapidly to downsize their TLS stacks. OpenSSL recently shipped version 1.1.0, containing a major revision of their state machine. Two OpenSSL forks, BoringSSL and LibreSSL have embarked upon more radical surgery, removing such features as Kerberos and SSLv2 (and in the case of LibreSSL, SSLv3). Similarly, NSS, the stack used by Firefox, has removed support for SSLv2 and disabled SSLv3 by default. Browser vendors have been even more aggressive: all four major browsers now disable RC4; IE, Chrome and Firefox no longer support SSLv3; and Chrome recently disabled finite field Diffie-Hellman, leaving only Elliptic Curve cipher suites for sites that want forward secrecy.

Second, we are in the process of simplifying TLS itself. The IETF is nearing completion of TLS 1.3, the first really major revision of TLS since the development of SSLv3. TLS 1.3 started by drastically reducing the number of cryptographic variants: converging on Diffie-Hellman key exchange (in a small number of predefined Elliptic Curve and Finite Field groups), authenticated by digital signatures or a pre-shared key. Removed features include: static RSA, static Diffie-Hellman, compression, stream ciphers, CBC-mode block ciphers, SRP, Kerberos, and everyone's favorite, renegotiation. The result is a version of TLS that is hopefully both stronger—because we have removed many dangerous and problematic features—and easier to implement and analyze.