After leaving users exposed, Apple fully HTTPS-protects iOS App Store (Updated)

Image from video demonstrating a password attack that was possible because Apple didn't fully encrypt traffic traveling between its App Store and end users

For the past nine months—and possibly for years—Apple has unnecessarily left many of its iOS customers open to attack because engineers failed to implement standard technology that encrypts all traffic traveling between handsets and the company's App Store.

While HTTPS-encrypted communications have been used for years to prevent attackers from intercepting and manipulating sensitive traffic sent by online banks and merchants, the native iOS app that connects to Apple's App Store fully deployed the protection only recently. Elie Bursztein, a Google researcher who said he discovered the security hole in his spare time, said in a blog post published on Friday that he reported various iOS flaws to Apple's security team in July. His post gave no indication that the iOS app had ever fully used HTTPS, raising the possibility that this significant omission has been present for years. (Apple doesn't comment on security matters, so it's impossible for Ars to confirm the precise timeline or level of protection.)

As most Ars readers know, HTTPS is a basic security measure that's almost as old as the Web itself. It ensures that traffic traveling between an end user and a webserver is encrypted. That prevents anyone who may have a connection between the two endpoints from listening in. HTTPS also provides cryptographic assurance that the server answering calls to itunes.apple.com truly belongs to Apple and not an impostor. Over the past five years, a growing roster of companies including Google, Facebook, and Twitter have begun offering end-to-end HTTPS, making it harder for attackers to use age-old exploits that bypass the measure. It's unclear why it has taken Apple so long to catch up.

Apple's failure to fully offer HTTPS for customers using their iOS app posed an unnecessary risk to anyone who has ever used their iPhone or iPad to download an app over an unsecured Wi-Fi connection. Attackers connected to the same network could use a variety of freely available tools and a clever social-engineering trick to retrieve passwords or other log-in credentials. Worse, they could set up fake App Stores that would issue fake apps and upgrades instead of the ones that would normally be issued by Apple's legitimate store.

At various points in Bursztein's post, which was headlined Apple finally turns HTTPS on for the App Store, fixing a lot of vulnerabilities, he said Apple recently "turned on HTTPS for the App Store." But later, he wrote: "By abusing the lack of enncryption (HTTPS) in certain parts of the communication with the App Store, the dynamic nature of the App Store pages, and the lack of confirmation, an active network attacker can perform" various attacks. That last statement suggests that parts of the App Store were protected by HTTPS while other parts were not. Bursstein has produced several videos that demonstrate the types of damage malicious hackers could have inflicted. The one below shows how an attacker on the same unsecured network as victims could have tricked them into installing a fake upgrade.

iOS App Store fake upgrade attack.

Paul Ducklin, a researcher at antivirus provider Sophos, has more here on why HTTPS protection for the App Store is crucial.

It's great that Apple has finally updated its iOS app for App Store to provide this basic protection for the entire site. But the work isn't over yet. SSL Labs, a report card system from security firm Qualys that rates the quality of websites' HTTPS protections, gives Apple's App Store a failing grade. iOS users shouldn't worry too much, since the weaknesses Qualys is detecting aren't easy for the average hacker to exploit. Still, it shows Apple engineers still have work to do to make its customers safe.

Story updated to change headline and first and second paragraph to add the words "fully" and "all." Language was also added to leave open the possibility that parts of the App Store were already HTTPS protected. Second and third paragraphs updated to change "protect" to "prevent" and add "almost" respectively.