Apple Delays App Store Security Deadline For Developers 25
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.
Really ? (Score:3)
. . . .it's not like Apple has a good record on SSL/TLS [theguardian.com]. Heck, other reports are noting that the Apple Store itself re-directs https connects to vanilla http connections. [ycombinator.com]
This is NOT Rocket Science. . . .
Re:Really ? (Score:5, Insightful)
. . . .it's not like Apple has a good record on SSL/TLS [theguardian.com]. Heck, other reports are noting that the Apple Store itself re-directs https connects to vanilla http connections. [ycombinator.com]
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: (Score:3)
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, the
Re: (Score:2)
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: (Score:2)
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 bac
Re: (Score:3)
. . . .it's not like Apple has a good record on SSL/TLS [theguardian.com]. Heck, other reports are noting that the Apple Store itself re-directs https connects to vanilla http connections. [ycombinator.com]
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 NSUR
Re: (Score:2)
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: (Score:2)
Why can't an app proxy non-compliant accesses through a server controlled by the developer?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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 re
Re: (Score:2)
Probably a couple decades.
Re: (Score:1)
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: (Score:2)
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 implem
"Apple" and "security" in the same sentence (Score:1)