Apple finally adopts HTTPS for the App Store - here's why it matters

Filed Under: Apple, Featured, Privacy

Last year, a Googler named Dr. Elie Bursztein noticed that Apple's App Store protocols weren't very secure.

Much of the interaction your iDevice had with the App Store was conducted via plain old HTTP.

Apple should really have been using HTTPS, or secure HTTP.

HTTPS, as you probably know, is HTTP traffic carried inside a Secure Sockets Layer (SSL) or Transaction Layer Security (TLS) wrapper.

→ SSL/TLS uses public-key cryptography to create a secure data channel, even between users or websites that have never corresponded before. Conventional encryption, like a doorlock, relies on a single key that can lock or unlock. How to share that one-size-fits-all key before you start using it is a security problem all of its own. Public key cryptography relies on an algorithm that uses two keys. One is kept private, and the other made public. What the public key locks, only the private key can unlock.

The problem with HTTP is that if you're on someone else's network, whether it's wired or wireless, they can probably listen into all your web traffic.

Likewise, if someone else is on your network, they can do the same thing, eavesdropping undetectably.

Worse still, it's very likely that they'll be able not only to watch what you're doing, but also to modify the traffic you send and receive.

So, in an ideal world, there would be HTTPS only, since the encryption layer inhibits both eavesdropping and unauthorised modification. Nobody would use HTTP for anything.

And why not? SSL/TLS encryption can be made largely transparent both to the programmer and the user, so the difference in online experience between encrypted and unencrypted web sessions is pretty modest.

In practice, however, HTTPS isn't quite as convenient for your IT department as HTTP.

You need to get certificates signed, your private keys stored securely, and more.

That means an operational change, which means paperwork, implementation time and (you can guess what comes next) money.

Also, because every HTTPS download is encrypted uniquely for each user each time they fetch it, it's much harder to cache HTTPS traffic.

If 2000 users from the USA pull down the same image file from your database in New Zealand, you can't rely on a web cache on the USA side to serve up an identical copy of the file to 1999 of them, because each download is individually negotiated and encrypted.

That means an operational change, which means paperwork, implementation time and (you can guess what comes next) money.

As a result, a sort-of HTTP/HTTPS hybrid evolved.

You use HTTPS for the parts of the transaction that really have to be secret, such as sending passwords, credit card numbers and other Personally Identifiable Information (PII).

For everything else, you use HTTP.

That was the model used by many online services, including webmail providers and social networks, until fairly recently.

Things started to change after the release of Firesheep, security researcher Eric Butler's mildly controversial effort to push the envelope of web encryption.

Implemented as a Firefox plugin, Firesheep listened on the network until the HTTPS-protected part of your social networking session was complete.

Then it sniffed out your session cookie, the magic token embedded in your post-authentication HTTP requests that tells Facebook, Twitter and others that you're an authorised user.

Firesheep could then pretend to be you, posting status updates, links, tweets and more from your accounts as if you had done it yourself.

Of course, even without actively hijacking your social networking accounts, an eavesdropper can learn an awful lot about you from your HTTP traffic.

After all, not everything you upload to Facebook or Twitter is inevitably intended for public consumption, so it oughtn't really to be uploaded without being wrapped in an SSL/TLS session.

Facebook, Twitter and others, bless them all, eventually bit the bullet and simply switched to HTTPS for everything. (At least, they did for web-based clients. Special-purpose mobile apps were, and some still are, a different story, but we shall ignore that issue here.)

But Apple, it seems, didn't bother with HTTPS everywhere, even for its own App Store, until 2013.

Since there's no other place to shop when you're buying or selling iDevice software, and since Apple likes it that way, you might think that Cupertino would have set the bar a bit higher.

You might also have expected Apple to react a bit more quickly after Dr. Bursztein's fairly detailed explanations of why the bar really needed to be higher.

In July 2012, he explained several problems, which he's now made public, including active attacks (that's where you change HTTP content en route between server and client) by which a malcontent could steal your password, trick you into buying the wrong App, deliver you a bogus update, or quietly prevent you from applying a needed update.

Burzstein also showed that the App Store routinely uploaded an unencrypted list of already-installed Apps from your device.

That doesn't sound like much, but it is.

Firstly, some of those Apps will identify aspects of your life that would be handy for a social engineer to know: the bank you use, the newspapers you like, the games you play, the share-trading services you invest with, and more.

Secondly, the complete selection of Apps on your device may very well be unique to you, thus making it a handy form of digital fingerprint for an attacker.

Earlier this year, Apple finally made a start towards the change that many of its web traffic competitors like Google, Facebook and Twitter made some time ago, and bumped all the App Store's active content to HTTPS:

Good. (Better yet would have been to serve everything using HTTPS, but let's be thankful for what we've got.)

If you're a web developer and your web services rely on users sending you traffic that contains anything at all that oughtn't to be public, you should be doing the same.

Even data that isn't legally considered PII can be pure gold to cybercrooks, and so leaking it could be putting your customers at risk.

And you wouldn't want that, would you?

Learning more about SSL/TLS

Would you like to know more about SSL/TLS?

Here's a quarter-hour Sophos Techknow podcast, featuring Paul Ducklin and Chester Wisniewski as they explain the S in HTTPS:

Listen now:

(03 August 2012, duration 16'10", size 11MBytes)

Listen later:

Download Techknow podcast

, , , , , ,

You might like

6 Responses to Apple finally adopts HTTPS for the App Store - here's why it matters

  1. Interestingly, naked security is not available via HTTPS, or at least not with a valid certificate: . But then again, this comment isn't exactly secret, and I hope the editing interface is secured, lest someone posts a "To get a facebook Gold Account, please enter your information at an https colon slash slash evil dot example dot com" news entry.

    • Paul Ducklin · 901 days ago

      The silver lining is that all comments that are published here are published globally, so the expectation is that they'll be 100% public anyway...there isn't any middle ground (e.g. like "friends of friends" on Facebook).

      And comments (as you see when you submit one) require approval by one of the team, so dodgy posts of the sort you mention should never appear. (One of us would need to be having a peculiarly bad day :-)

  2. Arerifx · 901 days ago

    Finally Apple listening..S for Secure

  3. TheOldShamrock · 900 days ago

    While I read and understand the article and beat myself up for not noticing this 'flaw' earlier, I do have a question.
    After reading the article, I logged on to the Apple Store thru my iTunes application on my computer (PC with Win7). No where on the iTunes window does it show the URL and the http or https status. How would I know if I'm connected, using iTunes, via HTTPS?
    I logged on to my account using Firefox and after I reached the login page (not very intuitive in itself) I did see the HTTPS in the URL prior to logging in.
    Note that I did not see a 'logout' button once I was able to get to my account so I'm not sure I fully logged out. Very strange and a place I won't go again.
    Still, it bothers me that I cannot see the URL or HTTPS in iTunes.
    Good article, by the way!

    • Laurence Marks · 900 days ago

      TheOldShanrock wrote: "No where on the iTunes window does it show the URL and the http or https status. How would I know if I'm connected, using iTunes, via HTTPS?"

      You could install Wireshark on your Win7 box. Start it before your iTunes session and start Capture. Run a brief iTunes session, Then stop the Capture and browse through the trace. You don't have to be an expert, or even study the individual packets. Just browse through the list and observe that some are HTTP and some (the active data) are HTTPS.

      • TheOldShamrock · 900 days ago

        Laurence...thanks. Yes, I could do this but I'm usually into more 'user usable' solutions even though I like to think I'm a bit more technically competent than the average user.
        I teach older folks basic computer skills and one thing I stress is the HTTPS and the 'lock' icon that appears on most browsers when they want to shop or do anything that requires personal information. Many of them have had their kids/grandkids set up iTunes as a way to get data onto their iPhones. Then they give them gift cards, etc. and show them how to shop.
        Anyhow, you get the picture. It would be nice if Apple would follow the defacto standards that others do.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog