Apple mandates App Store apps support ATS security protocol by 2017

AppleInsider

In an announcement at a Worldwide Developers Conference session on Tuesday, Apple said apps submitted to its various App Stores will be required to use the App Transport Security standard by the end of 2016, a decision that underscores the company's dedication to customer privacy.

Introduced as part of iOS 9, ATS transfers app data over HTTPS connections instead of HTTP, thereby reducing the potential of user exposure to nefarious code or data theft. Starting Jan. 1, 2017, all new apps and app updates submitted to the App Store will need to support the protocol, reports TechCrunch.

ATS is turned on by default in Apple's development tools, though developers currently have the option to deactivate the security feature if they so choose.

Apple's upcoming deadline mirrors a wider industry shift toward HTTPS-based connections. Banks and internet service providers dealing with highly sensitive user data were among the first to deploy HTTPS solutions, and an increasing number of companies have since adopted similar safeguards. Device manufacturers marketing bespoke operating systems, like Apple's iOS and Mac, have followed suit.

ATS found itself at the center of a small controversy last year when Google publicly disclosed a technique of sidestepping the iOS security protocol with just a few lines of code.

Google discovered that ATS was blocking ads from displaying correctly in certain mobile apps, which presented an obvious threat to its lucrative advertising business. In response, the internet search giant posted a "short term fix" to its Ads Developers Blog proposing developers inject HTTPS exceptions into their apps. By allowing non-secure HTTP requests to succeed, these exceptions inherently put users at risk.

In any case, developers looking to sell their wares on Apple's App Stores will have no choice but to comply with ATS guidelines come January.

indieshack

Great in theory but in practice this will kill some apps stone dead which use third party web data. Very bad news.

visualseed

indieshack said:

Great in theory but in practice this will kill some apps stone dead which use third party web data. Very bad news.

A lot of data doesn't really even require it. Fetching weather or stock quotes for instance. Read only data that you pass no credentials to access.  If the sources want to use SSL, that's great, but many of them haven't been touched in years. Unless they see a revenue impact to their services by being banned from iOS apps, many won't do anything. 

indieshack

VisualSeed said:

A lot of data doesn't really even require it. Fetching weather or stock quotes for instance. Read only data that you pass no credentials to access.  If the sources want to use SSL, that's great, but many of them haven't been touched in years. Unless they see a revenue impact to their services by being banned from iOS apps, many won't do anything. 

And that's the problem. I have an app that I'm about to submit which uses public data from a non-profit scientific entity for which there is no https service. I've worked in outfits like that for years and switching on HTTPS can be a serious server load issue for them plus the certificate maintenance. It's dawned on me that Apple won't "switch off" apps already in the app store which use the ATS exception, so I'm likely fine for the time being but in my view it's a sledgehammer approach by Apple not helped by the poor communication from apple about ATS. 6 months isn't a reasonable timeframe to expect app data sources to switch and in my view this was a poorly thought out strategy brought in by bad Apple managers with poor foresight but with a view to pleasing their bosses by implementing a "privacy" strategy. It is what it is.

netmage

Fetching weather implies telling the Internet your location - is preventing an unknown middle man the ability to track your location important to you?

libertyforall

Why wait to mandate it in 2017 Apple?!  Push for it now in July for better security of your app users!  *rolls eyes*

lostkiwi

AppleInsider said:

ATS found itself at the center of a small controversy last year when Google publicly disclosed a technique of sidestepping the iOS security protocol with just a few lines of code.

Google discovered that ATS was blocking ads from displaying correctly in certain mobile apps, which presented an obvious threat to its lucrative advertising business. In response, the internet search giant posted a "short term fix" to its Ads Developers Blog proposing developers inject HTTPS exceptions into their apps. By allowing non-secure HTTP requests to succeed, these exceptions inherently put users at risk.

And these few lines neatly summarise why I despise Google.  'Do no evil', my arse. 

marvin

indieshack said:

Great in theory but in practice this will kill some apps stone dead which use third party web data. Very bad news.

The developer would setup an HTTPS server for apps to connect to and that server would connect to any unencrypted service to fetch the data. If there are a lot of app downloads, it may overload the developer's server so they'd need a cloud service for high load.

This is why IPv6 should have encryption enabled by default because it wouldn't require a certificate. All packets would be encrypted.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s1-ipsec-net2net.html

Apple could allow connections that support protocol encryption and even self-signed certificates to make it easier on developers. It wouldn't matter if it's a self-signed certificate because the important consideration is that the traffic is being sent encrypted and isn't intercepted.

indieshack

Marvin said:

It wouldn't matter if it's a self-signed certificate because the important consideration is that the traffic is being sent encrypted and isn't intercepted.

For publicly available data, think terabytes of specialized indexed data - there's really no need to encrypt it's download - it's a complete waste of CPU

marvin

indieshack said:

Marvin said:

It wouldn't matter if it's a self-signed certificate because the important consideration is that the traffic is being sent encrypted and isn't intercepted.

For publicly available data, think terabytes of specialized indexed data - there's really no need to encrypt it's download - it's a complete waste of CPU

There's no way for Apple to tell the difference between what kind of data is being transferred though. A lot of it is being captured by government agencies and apps are sending out all kinds of personal data.

CPU overhead for SSL isn't that high these days:

https://www.maxcdn.com/blog/ssl-performance-myth/

You can test it on the Mac in the terminal. With a large file like a video you can run the following command and the time taken to process would be user+sys times, there's disk IO with a file that wouldn't be there at the network level:

time openssl aes-256-cbc -a -salt -in (drag file in) -out (drag same file in and rename with e.g .enc on the end)

It takes seconds for hundreds of MBs of data and the CPU doesn't spike at all.

Having to set it up is the biggest problem for developers. Setting up a server and maintaining a certificate has more costs associated with it. If a developer has very few downloads, they can get by with shared hosting. $10/month with SSL unlimited bandwidth, drop a script on it to access an unencrypted service and pass the data along. Shared services would probably handle hundreds of thousands of downloads.

Apple must have exceptions for some apps as a browser can access unencrypted connections so they may allow exceptions for some hardwired connections. They have a presentation at the following link that talks about the move to encryption and treating all data as sensitive:

https://developer.apple.com/videos/play/wwdc2015/711/

It would be nice if the networking industry would make things easier as time goes on. They should separate encryption from authentication. Encryption should be done by default without expiring certificates. An authority should just check the encryption is adequate and verify the connection details and then provide a certificate that gets integrated with the encryption that's already there.