Understanding Apple's SSL/TLS Bug

Understanding Apple's SSL/TLS Bug

Yesterday Apple released updates for iOS 6, iOS 7, and Apple TV to squash a security bug that affected SSL/TLS connections. Often times, security patches can fix obscure bugs that could only occur under the strangest of circumstances, and they get rolled in to larger updates that address many other issues. However, this fix warranted its own updates, both for iOS 7 and for iOS 6. So what kind of bug calls for such a response? Fortunately for those of us curious enough to wonder, Adam Langley has the answer.

First of all, any time you have a bug that affects SSL/TLS you should pay close attention. As a quick refresher, SSL/TLS refers to encryption protocols that are widely and commonly used to encrypt the transmission of sensitive data. Any bug affecting SSL/TLS has the ability to undermine many, if not all, of the secure transmissions made from your devices.

The bug Apple fixed was the result of a stray line of code. It exists in a block of code that is responsible for validating the identity of a server. When your browser makes a secure connection to a website, the site presents your browser with certificate chain. Your browser will check the site's certificate to make sure that it's for the site you're connecting to: apple.com can't present you with a certificate that says it's for google.com. Your browser will also verify that the certificate was issued by a trusted certificate authority: I can generate a certificate for google.com, but I am not a trusted certificate authority so that certificate should not be accepted by anybody. Finally, your browser verifies the certificate chain's signature with the website's public key. Even if I create a fake certificate chain, the key I use to sign it won't match the site's public key. This is where Apple's code was failing. Below is the relevant snippet from Apple's published open source code:

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer     signedParams,
                             uint8_t *signature, UInt16 signatureLen)
    OSStatus        err;

    if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
        goto fail;
    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;
    if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
        goto fail;

    return err;

The if statements in the code above are part of iOS's signature verification for particular cipher suites that can be used in SSL/TLS. In the second if statement you see an if statement followed by two "goto fail" lines. The second one is the cause of the bug. The result of this code is the portion where the server's signature is validated never gets executed. The code attempts to validate the certificate, but after validating the certificate and before it validates the certificate's signature, the code will always hit that second "goto fail" statement, which effectively skips over that last bit; the part where the signature is validated. This bug affects any software that uses Apple's SecureTransport API for making SSL or TLS connections, including Safari and many third-party apps.

The result of this code is that an attacker on the same network as you could perform a man-in-the-middle attack where they fake a certificate keychain to a secure site, like your bank. You can't trust any secured connections in affected version of iOS and OS X. Everybody should update their iOS devices and Apple TVs if they haven't already.

Unfortunately, OS X remains vulnerable to this attack. Given the severity of this bug, it's surprising that Apple hasn't rolled out an OS X update yet, but we'll hopefully see one soon.

Update 1: People wishing to check to see if they're vulnerable can go visit the site gotofail.com. Safari in OS X will show as vulnerable until Apple deploys a fix, while Firefox and Chrome are not currently susceptible since they use different libraries for encryption.

Update 2: Apple spokesperson Trudy Muller has confirmed to Reuters that the OS X update is coming soon.

Have something to say about this story? Leave a comment! Need help with something else? Ask in our forums!

Nick Arnott

Security editor, breaker of things, and caffeine savant. QA at POSSIBLE Mobile. Writes on neglectedpotential.com about QA & security, and as @noir on Twitter about nothing in particular.

More Posts



← Previously

Where's iMessage for Android?

Next up →

What's on Ally's iPad right now!

Reader comments

Understanding Apple's SSL/TLS Bug


Great explanation. Curious, when was this bug introduced? Anyone know? iOS 6? Or iPhone OS 1?

Sent from the iMore App

Per the Ars Technica article; "the vulnerability has been confirmed in iOS versions 6.1.5, 7.0.4, and 7.0.5, and OS X 10.9.0 and 10.9.1".

Safari and Mail are known to be exposed while Chrome and Firefox are unaffected by this flaw and should be used by OSX users (as well as stay off public networks) until Apple provides a fix (I'm kind of stunned this article doesn't mention that).

I decided to leave out mentions of Firefox and Chrome to avoid confusion and a false sense of security. Adam mentions in his post that we linked to above "However, that doesn't mean very much if, say, the software update systems on your machine might be using SecureTransport." Even if Chrome and Firefox are currently not affected, when they are running on a system that can be compromised at a deeper level, their security is hard to guarantee. It's feasible that an attacker could undermine Chrome and Firefox by leveraging the SecureTransport bug elsewhere on the system. Until Apple fixes the root problem, it's difficult to guarantee safety in any app.

Though after giving this some more though I've added a note to the end of the article mentioning this. I also linked to gotofail.com for users to check for themselves so if Chrome or Firefox were to somehow become compromised, users would be able to see by checking for themselves. Thanks for bringing this up, Richard.

I don't know what it did except cause me to delete some of my apps so I had enough storage to down load it. Does not make me very happy! Can't you fix things and not take all my storage! Caused this on my iPad and I phone!

I feel Nurse's pain. I had 37 MB free to download the update but it wanted me to have 1.2 GB free to actually *install* it.

This is why we have code reviews. Would have found it pretty quickly.
(And, of course, yet another argument against using goto statements.)

If you really wanted to be clever and sneak the bug in intentionally:
Instead of adding an extra goto like this:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
goto fail;
goto fail;

Just add one extra character like this:
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0);
goto fail;

The extra ";" after the closing parenthesis ends the 'if' statement with a null body, so control always flows to the next statement. Therefore the following 'goto' is always executed.

The Mac/OSX vulnerability only applies to wi-fi connections, correct? If I'm simply using ethernet to my router at home, that's not vulnerable, right? Thanks for this article!

It's been 10 years since I've written any code, but I wouldn't take any chances, wifi, Ethernet or otherwise. I'm going to leave it at that bc I don't know enough to say one way or the other. Maybe sockrolid may be able to help?

Sent from the iMore App

Sorry, I have never seen the SSL/TLS code (other than the snippet above.) No idea what you need to do to avoid exposure (until the OS X patch is inevitably released.)

This is a transport level problem, WiFi and ethernet are a level below, i.e. it doesn't matter what you use to connect false certificates aren't always detected.

I should add to this that this bug is a "man in the middle" attack meaning that someone needs to be able to intercept your traffic to see it. If you trust all the internet providers involved then there isn't much chance of your communications being read.

Honestly don't believe so cause the fingerprints are held locally on your phone and the security is so right there's no way to get them off your devics

Sent from the iMore App

The big question in my mind is why this important piece of code wasn't laughed out of a review for more than 18 months. Why did it pass all the tests that apple ran? Edsger Dijkstra must be turning over in his grave.

Clearly, Apple's test processes do not call for sufficient code reviews. This is too elementary to miss otherwise. But then, Apple's code has never impressed me too much.

will this fix the bug that won't allow my iPad Air to connect to the internet from any public WiFi without at router restart? Its getting anoying to keep asking starbucks and my gym to reboot!

I have tried to google it, but does anyone know how to update an iPhone4 to 6.1.6 rather then iOS7?
My iphone4 runs like crap on iOS7, so we have not updated my wife's iPhone4.

I want it to be secure, but refuse to upgrade her iPhone to iOS7 as it ruins a fast iPhone4.
Has anyone seen or read if this is possible?

Although not entirely related, scathing report IMO on the slanted reporting against Apple by the popular media. Check out Apple Insider. 'Apple's failure to pay for favorable media coverage flies in the face of Samsung's payola.' Great to see a media outlet some may say Apple bias calling it like it is. Rene has mentioned this kind of negative Apple press on several occasions. Great read check it out.

Sent from the iMore App