SSL Vulnerability in Apple iOS (iPhone, iPad, iPod Touch)


Today, Apple quietly released an update for their mobile operating system, iOS:

  • iOS 4.2.10 for iPhone 4 (CDMA)
  • iOS 4.3.5 for iPad, iPod touch (3rd generation), iPhone 4, iPod touch (4th generation), iPhone 3GS

Note: this is a semi-technical article – if you prefer, you can jump straight to the Layperson’s Summary at the end.

Like many users, I don’t connect my iPhone to iTunes that frequently, so it was only coincidence that I was offered this update so soon after its release while I was taking a backup this evening.  As always, I took a look at the release notes (linked to above) and realised the wide and serious implications of the single flaw that is fixed in this update.  It is fairly unusual for Apple to push out an iOS update containing only a single patch, but despite the quiet, no-fanfare release of this update, I believe it’s actually pretty serious.  Also unusually, this vulnerability was patched within 10 days of Apple being notified – clearly they are aware of the significance of the problem.

iPhone shot by bullet with wispy neon trail - abstract image suggesting recent iOS update may have addressed the security issues after many devices had been attacked.

The problem identified by Gregor Kopf of Recurity Labs (on behalf of BSI) and Paul Kehrer of Trustwave’s SpiderLabs is probably (in security terms) one of the most significant vulnerabilities I can recall being uncovered in iOS.  For the technically-minded, it is similar in nature to a finding by Moxie Marlinspike in Internet Explorer in 2002, and relates to the way SSL certificates are checked for validity when opening a secure connection from your iOS device.  This does not only affect connections made by the inbuilt Safari browser, but potentially also the e-mail application and any other third-party application that connects to remote SSL services and uses iOS built-in functionality to check their validity – this could include your bank, PayPal, Facebook, Amazon, etc.

Technically, the vulnerability is down to the fact that when verifying the validity of an SSL certificate, iOS only appears to do the basics – it checks that the certificate is signed by a recognised and “trusted” Certificate Authority, or there is at least a recognised Certificate Authority somewhere in the hierarchy of signatures (the certificate chain).  What it wasn’t doing until this update, however, was checking that each certificate in the chain was actually allowed to sign the one below it.

I have a few SSL certificates, issued by a “trusted” Certificate Authority (CA), each of which includes properties (set by the CAS) that clearly state the certificates are not to be used to sign other certificates (the precise terminology here may differ depending on the tool you use to view certificate properties):

  • Key Usage = Signing / Key Encipherment / Data Encipherment
  • Enhanced Key Usage = Server Authentication / Client Authentication
  • Basic Constraints = End Entity / is not a Certificate Authority

Reportedly, it is this last property that is not being properly checked by vulnerable iOS installations, although the others relate to the same limitations imposed by the Certificate Authority.

Technically, there is nothing to stop me signing new SSL certificates with other certificates that were not intended for the purpose, but browsers (and other applications checking SSL certificates) should always present a warning to the user when a certificate is being used for unauthorised purposes.  iOS, until today, was not making this check, and therefore not warning the user that there was anything suspicious about the connection.

Using any of a number of Open Source tools, I am able to create new (fake) signed certificates for (e.g.),,,, etc.  Theoretically, I could even create certificates ‘on the fly’ depending on what connections I see on a network, or create a single “wildcard” certificate that appears to cover every domain on the Internet.  Now all I need to do in order to exploit the vulnerability reported today is to put together a couple of bits and pieces (laptop, a couple of scripts, wireless cards), wander down to my local coffee shop, bookshop or railway station, run up a fake “open” wireless Access Point with a common name, then wait for someone to connect to it and use an unpatched iOS device to access some SSL-secured Internet service.  I can then intercept (and, in fact, modify) their traffic without their device alerting them to the problem.  If I was in a really lazy mood, I could even do most of this with existing public tools (e.g. sslsniff and fakeap amongst others).

Of course, it is simple to intercept and modify non-SSL traffic anyway, but most people are already aware of this fact, and so generally check (when using public WiFi or GPRS/3G networks) that they are using SSL whenever they work with important or sensitive information.  In fact, since the release of FireSheep, which increased public awareness in this area, many of the more popular online services (e.g. Twitter, Facebook, Google Apps, Yahoo!, etc.) offer users the option of using SSL for everything, and in same cases even enforce it.

[Note: in order to succeed in a proper undetected attack, there are a couple of other things I would need to do to get myself into a “privileged network position”, as Apple describe it, but I’ve omitted that detail here to avoid handing too much information to the bad guys!]

Paul Kehrer is due to present this finding (amongst others) at DefCon 19 in August, in the context of demonstrating a new tool (SSLizzard) designed to help developers identify SSL-related vulnerabilities in mobile applications.  I am pleased, however, that Apple were given time to resolve this before the presentation at DefCon, as there are already easy-to-use tools available to detect and exploit this vulnerability – although they would need to be used in conjunction with other techniques to enable fully-undetected interception and modification of traffic, those techniques are also not difficult to deploy.

Most of the industry analysis and commentary so far has been focusing on the fact that iOS users could be attacked while using open WiFi connections, since this is the easiest mechanism for an attacker to use, but it is worth noting that attacks could take place over any network connection over which the SSL traffic runs (including GPRS/3G data connections) – the only difference is that the attacker might need some more sophisticated (and expensive) equipment available to them.

There has also been some hint in the technical media that this vulnerability is unlikely to be exploited in the wild because Windows (or other) users on the same network would see certificate errors in their browser.  This is true, if attackers were launching a rather unsophisticated exploit: it is not difficult to detect when an iOS-based device is present on a network, and in some cases it may even be possible to detect the version of iOS it is running.  This means an attacker could target specific devices and simply ignore, or “pass through” all other traffic they intercept.

One significant fact also seems to have been given only minor coverage in mainstream reporting on this issue – the vulnerability has very likely been in iOS since it first came on the scene, and yet we have no idea whether anyone with malicious intent ever noticed (and exploited) it before Apple’s fix on 25 July 2011.  Think about how long we have had iPhones, iPads, iPod Touches, etc. and how many times we have trusted SSL to protect us from anyone intercepting our traffic, or to confirm that the server we’re connecting to is what it says it is – theoretically, any one of those connections over the years could have been breached without us noticing.

Another concern with the patch, and (due to its very quiet release) the lack of general awareness of the problem – it does not apply to any Apple device that has fallen out of support (i.e. anything older than those listed at the beginning of this article).  Users of older devices, or those that have been “jailbroken” and are hence also unsupported, will forever be vulnerable to this issue – this is doubly worrying as there is no simple method by which an iOS user can check the details of SSL certificates in use for websites, applications, etc. – some details can be viewed if you encounter an invalid certificate, but I can’t find anything in standard iOS that allows you to view the properties of “valid” certificates (if there is a way, I’d love it if someone could tell me where it is!).

Patch, patch quickly and cross your fingers that:

  1. There aren’t any other hidden problems in the iOS crypto layer; and
  2. Nobody other than Apple and SpiderLabs/Recurity knew about this problem before today!

Layperson’s Summary

In summary, there has recently been an update to all Apple mobile devices (iPad, iPhone, iPod Touch) currently under support that fixes a very significant problem with how those devices check the validity of SSL certificates. These certificates are used by your device to verify the authenticity of secure services, such as your bank, PayPal, social networking applications, even your e-mail. SSL certificates are also used to encrypt all traffic to and from those services.  When using a secure connection, you would expect to be warned if the SSL certificate is invalid or has changed – prior to this update, you might not have received such a warning in certain circumstances, which means your traffic could be viewed and/or modified by anyone able to access the same network as you. This could happen across a public wireless connection or even your mobile data network without you being aware.

If your device is still supported, you can get the update in the usual way (by connecting to iTunes and accepting the update), but if you use an older device (or, in fact, a “jailbroken” device) there may not be an update available for you, and I am not aware of Apple planning to release one.  If you have an unsupported device, I’m afraid your options are limited – just be very cautious when using any service that relies on SSL to protect traffic. I recommend that you only use such services on a network you completely trust.

Good enough to Share?

Author Profile: Peter Bance

Peter Bance I started work in IT when only the Doctor had to worry about "Cybermen", and a "Cloud" was a fluffy white thing you'd occasionally see an aeroplane fly through! As an independent Information Security consultant, I have worked with numerous public and private sector clients through the years, and I have been a CLAS Consultant advising Government for over a decade. This is my Web site, so to find out more about me, just have a look around!

Please feel free to leave a response below. Pinging is currently not available . If you are interested in tracking blog comments too, please subscribe to one of my comment feeds.

6 Responses to “SSL Vulnerability in Apple iOS (iPhone, iPad, iPod Touch)”

  1. Thanks very much for this excellent article. I was surprised to be able to understand this. One question. I’ve heard of signing and understand what server authentication is, but don’t think I have come across this before: “Basic Constraints = End Entity / is not a Certificate Authority”. Please could you explain what this means?

    • Peter Bance

      I’m glad you found the article helpful. The Basic Constraints section of an SSL certificate is set by the Certification Authority (e.g. Verisign, Comodo, etc.) and defines what the certificate can be used for. You can view the Basic Constraints section of any certificate by viewing its properties (in Internet Explorer, click the padlock in the address bar, in Firefox click the highlighted domain name at the beginning of the address). A ‘normal’ website certificate will have the Basic Constraints section set to ensure the certificate can’t be reused to sign new, subsidiary certificates.

      The contents of the Basic Constraints section are presented in different ways in different browsers (within the certificate itself, it’s actually just a boolean, or yes/no value):

      • Internet Explorer: End Entity
      • Firefox: is not a Certificate Authority

      The Certificate Authority (CA) sets this flag because the validation process they employ when issuing a single server certificate is not highly rigorous – it does not infer sufficient trust in the server’s owner to allow them to become a Certificate Authority themselves (and thus be able to sign other certificates).

      You can check this out for yourself – compare the following, for example:

      View the certificate details for each of the above sites (you’ll have to look through the detailed “Certificate Properties”), and you will see that the Basic Constraints section is correctly set on the first one, whereas on the second it is not – that test certificate has been created specifically to test for this problem in iOS.

      I hope this helps, but do drop another comment back to me if I haven’t explained it clearly!

      • Thanks for the extremely detailed response. I feel like I’ve got my own personal mini article! I had to read it twice but I think I get it. I even got your joke about iOS ;-)

        So, if I’ve got this right, the SSL certificate is produced by a Certificate Authority, who would be the trusted source. And the iPhone (or whatever) is designed by Apple (or whoever) to look for these and trust them when they are set up right. And the End Entity says that the iPhone can trust the certificate (and person who holds it) to provide certain things, such as Internet banking or keeping personal data. Is that right?

        I really do appreciate you taking the time to explain all this to someone you just ‘met’.

        • Peter Bance

          “Thanks for the extremely detailed response. I feel like I’ve got my own personal mini article! I had to read it twice but I think I get it. I even got your joke about iOS ;-)”

          No problem – this happens to be a topic of significant interest to me, so it’s quite good to have the opportunity to talk about it. I’m considering writing a separate article explaining SSL certificates, the “trust hierarchy” etc. when I get the chance – you might want to watch out for that.

          “So, if I’ve got this right, the SSL certificate is produced by a Certificate Authority, who would be the trusted source. And the iPhone (or whatever) is designed by Apple (or whoever) to look for these and trust them when they are set up right. And the End Entity says that the iPhone can trust the certificate (and person who holds it) to provide certain things, such as Internet banking or keeping personal data. Is that right?”

          Almost there – the phrase “End Entity” might have confused things a little here. This is Internet Explorer’s way of saying that the boolean flag for “Certificate Authority” is not set on the certificate – Firefox is more clear when it says “is not a Certificate Authority”. In fact, iOS itself is pretty clear when you do get to view certificate properties (as far as I can tell, this is only when there’s an error) – it has a section in the certificate properties marked “Certificate Authority” with a “Yes” or “No” against it.

          A Certificate Authority is a top-level authority that is “trusted” to sign certificates. If you look even deeper into your browser settings (again, exactly how will vary with your browser), you should be able to find the list of Authorities your browser inherently trusts (this includes the likes of Verisign, Comodo, Thawte and a large number of others you may not have heard of). Each of these may have “Intermediate” certificates which are also classed as “Certificate Authorities”, as there is a “chain” or “hierarchy” of trust involved. When a Certificate Authority signs a certificate destined for an SSL server, it marks the “Certificate Authority” section of the “Basic Constraints” section to “No”, meaning that the certificate is not trusted to sign others (and thus create a longer “chain”).

          So, taking the CLAS Consultants site I mentioned before as an example:

          1. GlobalSign Root CA is the top-level Certificate Authority – this certificate is pre-installed in your browser (or in the system beneath it, such as iOS, Windows or anything else) as a “trusted” Authority. Under Basic Constraints, this certificate is a Certificate Authority.
          2. GlobalSign Domain Validation CA – GlobalSign has chosen to create a sub-authority (intermediate certificate) for the purposes of their “Domain Validation” service (this means they have only checked that I officially administer the domain that the SSL certificate applies to). Again, this intermediate certificate is a Certificate Authority.
          3. – this is the certificate I received to install on my server once GlobalSign had finished their verification. This certificate is not a Certificate Authority – it is an “End Entity”, and therefore is not authorised to sign other certificates.

          The difficulty arises because technically any certificate can be used to sign any other (well, strictly, it is the associated private key that is used to sign, but that’s detail for another day!). So, even though GlobalSign has said I shouldn’t use my certificate to sign any others, there’s no reason why I can’t – for example, I can use the certificate to sign a new certificate for and start using SSL for this site. If I did this, though, pretty much every browser would complain about an invalid certificate. In your example, the responsibility for making sure this check is made lies with Apple (who produce both iOS and the built-in Safari browser).

          “I really do appreciate you taking the time to explain all this to someone you just ‘met’.”

          As I say, no problem! Watch out for a future article that will cover this in a lot more detail, and go into exactly how the “trusted” Certificate Authorities become trusted.

          • I think I understand this now. I’ve been reading about some of these terms on other websites and I was starting to get the idea, but I guess I needed someone to talk me through it.

            I don’t work in this area, but I keep seeing mention of SSL certificates in my browser so I wanted to find out what they were. I didn’t realise you also had SSL certificates in iPhones, but that was dumb of me because it of course has a browser. I get it now you’ve explained it. I’d like to request that article you’re planning on SSL, as it would certainly be of interest. Thanks very much Peter You are a patient teacher and very kind for taking the time. Great website.

          • Peter Bance

            No problem at all.

Respond to “SSL Vulnerability in Apple iOS (iPhone, iPad, iPod Touch)”

To leave a comment, please log in below. Not yet registered? It's quick and easy - just fill in my five-second registration form and a password will be emailed to you.

Blog Article Feeds

You can subscribe to my articles (blog posts) in several ways:

  • Newsfeed icon
    All posts [RSS]
    (you'll receive an update whenever I post a new article to my blog)
  • Newsfeed icon
    All posts [Email]
    (as above, but you subscribe to my list server, which sends you an email every time there is a new article to view)

The above subscriptions do not apply to comments - if you'd like to receive those, see the feeds to the right.


If mention of RSS and list servers has you scratching your head, just take a look at my Help page and I'll talk you through it.

Comment Feeds

Would you like to subscribe to a feed so you are notified when someone has commented on this article? Please select a feed to control the types of comments you receive:

I do not currently offer an email-based subscription option for following comments, but please contact me if you would prefer to receive discussion updates via email, and I will put it in place if there is enough interest. There are also separate feed and email subscription options for blog posts to the left.

Contact me now to discuss your consultancy needs
"I would have no hesitation in recommending Peter for work on any Government IT programme requiring accreditation. He was knowledgeable on all aspects of Information Assurance." — Pan Government Accreditor

Log InHelpContact