You could miss it if you weren't paying close attention through all the Heartbleed blather, but last week Apple patched a severe problem in their TLS/SSL code in iOS and OS X. An attacker in a privileged position, i.e., between two parties engaged in SSL/TLS (henceforth just "TLS"), could intercept and decode communications or inject commands and data.
The bad news is that this isn't just a bug in Apple's code; it's a bug in the TLS protocol itself, a protocol which appears to be quite a mess.
Professor/Cryptographer Matthew Green of Johns Hopkins says that the triple handshake changes our concept of what security means in the context of TLS. (He has also decided to learn one lesson from Heartbleed: When it comes to bugs, branding is key, and so he calls it "3Shake" and has commissioned the nearby logo.)
Apple credits the report of the bug, now CVE-2014-1295, to Antoine Delignat-Lavaud, Karthikeyan Bhargavan, and Alfredo Pironti of Prosecco at Inria Paris, and describes it in this way:
In a 'triple handshake' attack, it was possible for an attacker to establish two connections which had the same encryption keys and handshake, insert the attacker's data in one connection, and renegotiate so that the connections may be forwarded to each other. To prevent attacks based on this scenario, Secure Transport was changed so that, by default, a renegotiation must present the same server certificate as was presented in the original connection.
Delignat-Lavaud, Bhargavan and Pironti found this a while ago and, in the best traditions of research, have been disclosing it confidentially to those responsible for affected software. Read far more gritty detail on the attack, variants of it, and the progress of remediation at their web site.
The image below demonstrates how the attack works. Don't try too hard to understand it. Professor Green describes it as "absolutely insane."
I'm not going to try and elaborate on the explanation, as I don't think there's any simple and honest way to explain the mechanism. It's a man-in-the-middle attack with full takeover control. That's what you need to know. And it affects many TLS implementations. Yes, it requires that the attacker be in a privileged position, but effectively Heartbleed does too, because you need to get the traffic somehow in order to decode it.
Which implementations are affected and which have been remediated? Delignat-Lavaud, Bhargavan and Pironti maintain a partial list in the "Disclosure and Vendor Response" section of their web site. Not all TLS implementations and applications are affected, though a large number are. Of course we know that Apple's was affected and has now been fixed. Some notable status reports:
- SChannel (Internet Explorer): notified October 18, 2013. Security update under test
- OpenSSL, GnuTLS: notified on October 20, 2013. Not directly affected, but applications using them usually are. Mitigations pending adoption of new TLS extension
- NSS (Chromium,Firefox): notified November 4, 2013. Prevented degenerate Diffie-Hellman public keys in CVE-2014-1491. Firefox correctly checks server certificates during renegotiation. (So it's fixed.)
As Green describes, the triple handshake is an abuse of features (he uses the term "band aid") which were put into TLS in order to fix previous man-in-the-middle attacks. TLS has several methods of "handshake," which is the ritual communication performed between parties in order to establish a secure connection. 3Shake requires that the parties use certain of these methods and it's not clear to me how often they are used, but the feature wouldn't be in there if someone didn't want it.
There are several solutions proposed by the researchers who reported the triple handshake to Apple. The temptation will be to do what Apple did, to put another check in to the handshakes ("...a renegotiation must present the same server certificate as was presented in the original connection."
But Green argues that the problem is the mess the protocol has become. Recall that TLS began life as a hack built by Netscape for their browser in the days when version 0.1 was good enough to ship. Over the years features and fixes have been added mostly because someone demanded them, not because any clear review was given to what we need TLS to do. The protocol came first, then the analysis of it.
Unfortunately, it's a bit like SMTP, whose problems we are doomed to suffer for all eternity. Too many people rely on the messy TLS we have right now to change it on the fly. Make a new fixed-up and clean TLS 2.0 and nobody will use it. Every now and then a transition is made from a badly insecure product to a more secure one — the transition of old Microsoft Office file formats to the new ones comes to mind — but the transitions are painful and I bet, if there isn't a very powerful party to force things, like Microsoft with their Office code, the transition just won't happen.
Time for the IETF TLS Working Group to stock up on band-aids.