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

ATS. No documentation found.

[Anonymous Coward]

We just spent the last month getting ready for this and at the last minute you move the goal posts?

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.)

Re:Really ?

[LifesABeach]

My concern on how Apple fucks developers around is that NOW your app has to sell for 99 cents! WTF! But wait! There's More! There is some special secret way, in other words "not published" that allows one to show their app for free!. The dumb ass in charge of a simple store that offers only web apps is the wrong person to run this part of Apple.

Re:Really ?

[countach]

They're only forcing ATS on apps where it is appropriate. Like where the developer controls their own server. Obviously forcing ATS onto something like say, Chrome browser whose reason for being is to connect to random servers, isn't caught up in this. Apple aren't completely stupid, even though they can be bloody annoying at times.

Re:Really ?

[countach]

Apple have said its only mandatory where it makes sense. Where it is fundamental to the app that be able to connect to random servers, they won't force it.

Re:Really ?

[Just Some Guy]

WTF are you going on about?

Re:Really ?

[Anonymous Coward]

They're enforcing it right across the board. This is incorrect

Re:Really ?

[Anonymous Coward]

This doesnt sound like the draconian apple we all know and hate.

Re:Really ?

[dgatwood]

I've seen nothing to indicate that it was ever intended to apply only to content hosted on developers' servers. The original articles all said that ATS exceptions would go away, and that only web views would be able to make noncompliant requests, which breaks as soon as you add NSURLProtocol into the mix. Maybe that wasn't the perception Apple intended to create, but it is the one they created. (Or, more likely, that was the perception they intended to create, but they got so much backlash that they backed down. Either way....)

BTW, I haven't looked at the iOS Chrome source code, but at least on other platforms, Chrome uses its own networking stack built on top of plain old TCP sockets. Chances are, the iOS version does, too, in which case it wouldn't be affected by ATS anyway. Other browsers, not so much.

Re:Really ?

[tepples]

Why can't an app proxy non-compliant accesses through a server controlled by the developer?

Re:Really ?

[tlhIngan]

Yes, the App Store does use plain HTTP connections - these are for the files downloaded so they can be rapidly and easily cached by CDNs. This is fine since the files are already internally signed and once downloaded, the signatures are verified. About all you can do is replace one app with another, so instead of downloading Pokemon Go, you end up downloading Angry Birds. (But even the IDs can be verified so this doesn't happen). Using HTTPS can hide the details of the app from snoops, but that's all it really does.

Heck, even iOS updates are on plain HTTP servers, again, for easy edge caching by CDNs But again, there are higher layer protections for the data that makes the transport irrelevant. You can't corrupt the data (it's signed by Apple), you can only replace it with another Apple-signed file.

All the sensitive data (purchases, etc) are handed by HTTPS to protect the data, and it doesn't pay to cache it, either.

And the big reason for the delay would mean some big app owner hasn't fixed their apps yet. Perhaps it was Facebook or Microsoft Office or something.

Legacy Apps

[Anonymous Coward]

TFA says this will be enforced at the App Store level. How long until they decide to enforce it at the iOS level and effectively kill off legacy apps which aren't being maintained any more but are still used daily by gobs of people?

Re:Legacy Apps

[Dog-Cow]

Probably a couple decades.

Re:Legacy Apps

[TheFakeTimCook]

Probably a couple decades.

If the earlier lesson with the "Sandboxing" requirement deadline is any indication, we're talking a few months, not a few years...

Re:Legacy Apps

[dgatwood]

Besides breaking a lot of apps, what good would it do to enforce it? It would take all of a day to write a basic emulation layer to pass NSURLRequest objects to libcurl. This already got delayed once by six months, and now it is delayed indefinitely because it breaks major apps by major companies in ways that can't readily be fixed without abandoning Apple's networking stack, which some folks are probably already doing in response. The policy backfired, and chances are good that it will *never* be implemented, because doing so would make the platform as a whole less secure rather than more.

"Apple" and "security" in the same sentence

[fbobraga]

Is not a FAIL?

They Already Threw the Switch

[Anonymous Coward]

I had to start requiring SSL since October. This is baked into Xcode. I had to get an SSL site for testing and everything.

I guess I can switch that off, now.

I'm not surprised.