Apple Delays App Store Security Deadline For Developers

Reader Trailrunner7 writes: Apple has pushed back a deadline for developers to support a key transport security technology in apps submitted to the company's app stores. Officials said at the Apple Worldwide Developers Conference earlier this year that developers would have to support Apple Transport Security by the end of 2016. But on Thursday, the company announced that it has decided to extend the deadline indefinitely. ATS is Apple's collection of transport security standards designed to provide attack resistance for data that's sent between iOS and macOS apps and backend servers. It requires apps to support a number of modern transport security technologies, including TLS 1.2, AES-128 or stronger, and certificates must be signed using SHA-2. ATS also requires the use of forward secrecy, a key-exchange method that protects encrypted sessions even if the server certificate is compromised at some point in the future.

Comments

Really ?

[Salgak1]

. . . .it's not like Apple has a good record on SSL/TLS. Heck, other reports are noting that the Apple Store itself re-directs https connects to vanilla http connections.

This is NOT Rocket Science. . . .

Re:Really ?

[TheFakeTimCook]

. . . .it's not like Apple has a good record on SSL/TLS. Heck, other reports are noting that the Apple Store itself re-directs https connects to vanilla http connections.

This is NOT Rocket Science. . . .

Obviously, they had significant grumbling from the Dev. community.

But this is like when they pushed-back the Sandboxing requirement a few years ago: It will happen.

How about a little less negativity, and a little more support for Apple at least attempting to drag Devs. into using more robust security?

Re:Really ?

[dgatwood]

. . . .it's not like Apple has a good record on SSL/TLS. Heck, other reports are noting that the Apple Store itself re-directs https connects to vanilla http connections.

This is NOT Rocket Science. . . .

Indeed, I used to work for a company whose app's downloads got blocked in various countries because the URLs were sent in the clear. My snarky comment was that app developers will care about web security as soon as Apple does.

But the big reason the ATS mandate was absurd is that lots of apps have to be able to download arbitrary content from arbitrary URLs, and web views aren't necessarily involved. And even when they are, developers often need to work around limitations in iOS WebKit by using custom NSURLProtocol subclasses to manipulate web view traffic on its way out (e.g. adding custom headers, authentication credentials, etc.). With ATS enabled, doing that becomes impossible.

So yeah, mandatory ATS was never going to fly, and lots of us said so almost immediately after the announcement. I'm glad they finally got the message.

Re:Really ?

[dgatwood]

The sandboxing thing drove a number of very high-profile developers from the MAS, and is widely regarded as a complete failure, both because of that and because it prevented entire categories of apps from being available through the MAS, eliminating any possibility of most users realistically choosing to limit their Mac to only MAS titles and thus significantly reducing its utility as a curated app distibution channel.

They should not be in a hurry to repeat that mistake. At least on the Mac platform, there was an alternative—direct distribution. Apple won't allow that om iOS, so entire categories of apps, if forced to enable ATS, would have only two options: Switch to libcurl with an emulation layer or leave the iOS platform entirely. (See my comments elsewhere about this breaking any app that deals with user-entered URLs for non-web purposes and also breaks web views when backed by custom NSURLProtocol subclasses.)