Technology News

latest updates from easySERVICE™

Apple recently patched a vulnerability in SSL/TLS code in iOS and OS X. No, not Heartbleed, but one which is, in some ways, worse


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.”


Triple handshake attack. The attacker mediates two handshakes that give MS on both sides, but two different handshake hashes. The resumption handshake leaves the same MS and an identical handshake hash on both sides. This means that the finished message from the resumption handshake will be the same for the connections on either side of the attacker. Now he can hook up the two without anyone noticing that he previously injected traffic. Image credit Matthew Green.

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. Shake 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.

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.

Source: Associated Press


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


This entry was posted on April 28, 2014 by in Apple, Malware, Security and tagged , , , , , , , .
%d bloggers like this: