Communications of the ACM
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!
No entries found