Skip to main content

Understanding Apple's SSL/TLS Bug

Yesterday Apple released updates for iOS 6, iOS 7, and Apple TV to squash a security bug (opens in new tab) 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 (opens in new tab):

static OSStatusSSLVerifySignedServerKeyExchange(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;...fail:SSLFreeBuffer(&signedHashes);SSLFreeBuffer(&hashCtx);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.

32 Comments
  • 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).
  • Thanks! Was looking for a way to circumvent this on my Mac in the mean time. Sent from the iMore App
  • 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.
  • Hey hey Sent from the iMore App
  • 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!
  • Use iTunes.
  • You didn't have 37MB free on your phone and iPad?
  • 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.
  • After deleting apps and installing I only have 668 MG now.
  • whenever I come to imore I always see news of a new security bug!
  • This is why we have code reviews. Would have found it pretty quickly.
    (And, of course, yet another argument against using goto statements.)
  • Also an argument for curly braces even on one liners... Sent from the iMore App
  • 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.
  • Great read! Sent from the iMore App
  • 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.
  • Could this security flaw have exposed our fingerprints from the 5S?
  • 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
  • No.
  • Yay! N Sent from the iMore App
  • Thanks for the explanation. iMore rocks. 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?
  • Unless the device is jailbroken, you're pretty much out of luck.
  • 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
  • So where IS this patch that takes up so much memory then?