Apple Doesn't Encrypt Downloads, Exposes More than 1Billion iPhones and iPads to Serious Privacy Threat—On Purpose?!

ANYONE with network access (ISPs, Big Brother, etc) knows the apps, videos, music, books, and other stuff you download through Apple and can trace that activity to hard unique identifiers for your device and Apple account

During development of our new iOS app (that makes it easy for you to see all the behind the scenes network traffic on your iPhone or iPad) we were shocked to discover that everyday thousands of background network requests were unencrypted. This means that your internet service provider (ISP), nation-states, or Wi-Fi snoopers can track all sorts of very personal details about your online activity.

We knew tons of websites and apps sent unencrypted traffic, but we were surprised to discover that Apple itself doesn't use TLS (Transport Layer Security) to encrypt the HTTP traffic to and from your iPhone or iPad. This means, for example, that every time you download or update an app from the App Store or content (music, movie, TV, etc.) from iTunes, it is sent in the clear over HTTP.

And even worse, each download / install from Apple includes unique hard identifiers like your device ID and DSID (destination signaling identifier) as HTTP headers in the clear.

alt

Failing to encrypt these headers, permanently ties your activity to your device and you personally!

After failing to get Apple to fix the issue, we contacted Lily Hay Newman at Wired who wrote about our research.

What's the big deal?

Of course all of this personal information sent unsecured is monetizeable data in the hands of Verizon, AT&T, T-Mobile, Comcast, and other global ISPs. And yes we already know that Trump's 2017 repeal of privacy rules for ISPs effectively allowed US based ISPs to mine any HTTP traffic data including browsing history. We're sure these ISPs are very happy to have access to all of your Apple install / download information; this information says a lot about your politics, income, sexuality, and a whole lot more about who you are and what you do online and off.

The Apple privacy hole would also allow governments around the world with network access to easily track who installs what apps and potentially even to censor certain apps and content from being downloaded without having to bother Apple with a take down notice or subpoena. We don't know that this type of government censorship or surveillance is happening, but it is technically possible. So why doesn't Apple just fix this threat and support HTTPS for installs and downloads like they do for all of their user facing HTTPS web pages?

Apple's reply: this is expected behavior

We reached out to Apple through their Radar bug reporting system on September 20th to describe the issue. On September 24th, Apple developer relations told us that the behavior was "expected". We then reached out to Apple personally, but received no substantive reply.

For two months, we sat around scratching our heads trying to figure out why Apple would not just make the easy fix to secure a serious privacy threat to literally all of their billion plus active iPhone and iPad devices. We are still scratching our heads.

Apple clearly understands the privacy and security benefits of encrypted HTTP. They use TLS on all of their user facing web pages and assets. And since 2016 Apple has required its developers to use TLS (by default) in the apps in their App Store to protect users. So why is Apple not protecting all iPhone and iPad users globally from this serious privacy threat?

Without all the facts, we are left to theorize on why leaving this information unsecured might be good for Apple's business interests.

Quoting from the Wired article cited above: "iOS researcher Will Strafach says he thinks the setup serves a specific purpose. By sending the downloads themselves over plaintext HTTP instead of an encrypted connection, system administrators, especially in large enterprise environments, can create a sort of way station to cache large apps and files on their local network for faster distribution. That means they won't eat up bandwidth if the app, update, or other file is being downloaded over and over again onto numerous devices. If the connection were encrypted between Apple's servers and the devices, that stopover wouldn't be possible."

After looking into this, the enterprise install explanation doesn't seem to make a lot of sense. First, Apple requires a Mac to cache app installs on enterprise networks. Apple could easily use TLS and cache encrypted app and iTunes downloads the same way they already encrypt content like your iCloud photos. Apple's own documentation makes this clear:

"iCloud caching stores the files users have in iCloud, such as Pages or Numbers documents.

All cached iCloud content is received, stored, and transmitted encrypted, and the content cache does not have the ability to decrypt it."

So why does Apple need to send unencrypted apps, music, videos, and more from it's own servers to its own software just to cache? The answer seems to be that Apple doesn't have to do this and could easily figure out a way not to send this unencrypted traffic

Second, an estimated +95% of Apple's billion plus active devices will never use a caching server, so why subject all these users to an easily fixable and serious privacy threat?

Hard for us to imagine that Apple would allow this privacy threat to exist for personal gain (e.g., a data sharing agreement with ISPs) or to sneakily avoid thorny government policy issues (e.g., creating a loophole for surveillance and censorship without having to get directly involved), but without more information from Apple we are left wondering what gives.

Our new iOS app protects against this privacy threat

The new Disconnect Pro for iOS is our best app yet and protects you from the threats described above by encrypting all HTTP requests, including app installs and iTunes downloads. Read more about our iOS Pro app [include link]. Or install the app for free.

If you have any thoughts on this topic please feel free to reach out to us, or join the conversation on Twitter.