What was supposed to happen on January 1st: <a href="https://datatheorem.github.io/ios/ssl/2016/08/14/ats-enforced-2017/" rel="nofollow">https://datatheorem.github.io/ios/ssl/2016/08/14/ats-enforce...</a> .<p>"The overall approach the App Store review team will take when it comes to ATS exemptions was summed up on the Apple developer forums:<p><pre><code> “The goal here is to flush out those folks who, when ATS was first released, simply turned it off globally and moved on. That will no longer be allowed.”
</code></pre>
Hence, for a given App going through the App Store review process:<p>* An easy policy to justify is to have NSAllowsArbitraryLoads disabled and a list of domain-specific exemptions for third-party domains the App connects to.<p>* A policy that will be harder to justify is to have NSAllowsArbitraryLoads enabled and a list of domain-specific “un-exemptions” for the domains you control.<p>* Lastly, a policy that will definitely trigger a rejection, as stated by Apple, is to have NSAllowsArbitraryLoads enabled with no additional ATS settings.
"<p>Since most Apps are not compliant yet, the App Store review team would have had to review every justification for every App and make a decision on whether to allow the App on the Store or not.
The apps at my F50 employer are in no way compatible with these requirements, and getting all the VPs to care about this is unlikely to ever reach even the minimal level of concern. Of course this is sad and stupid and shortsighted but unless Apple enforces it and our apps were refused updates nothing will ever change.
This does not sound like the Apple I know about.<p>I mean, these guys forced every app to be able to handle IPV6-only network operations last year. And this was after making all apps switch to 64 bits a bit earlier. Why did they back up off SSL?<p>I feel like this is kind of a turning point, where Apple, instead of driving the market with innovative APIs and having a vision, now tries to compromise and removes innovative features to keep its immense app market happy, and oblige for it.<p>What a let down, especially after a very nice 2016 year, where they stood against the FBI and published their open letter about privacy of their customers.
The title at the time of posting reads: "Apple Delays iOS SSL Requirement Indefinitely."<p>"Indefinitely" while technically accurate also implies "unlimited period of time." The article says there will be a deadline, it just hasn't been determined as of yet.<p>A better title may be "Apple Delays iOS TLS App Requirement." Just simply chop off the word "indefinitely." And throw in App to differentiate it from a e.g. Safari TLS requirement. Also TLS instead of SSL.
They probably just don't want to break a bunch of applications that haven't updated yet. It would be nice if they could make it a configurable option for those of us who don't use / care to use apps that are still not using HTTPS. "Allow Secure Connections Only" checkbox in Settings or something.
It was always a nice way to force my customers to implement HTTPS, the threat of Apple rejecting or removing the app. It's pretty easy to implement and inexpensive so why people still don't do it is a complete mystery to me.
Glad to see this. I'm about to release a new version of my app (a news reader, which makes extensive use of webviews), and I was sweating about this. I don't control any of the news sites that we interface with, and I was surprised to see that most don't support SSL.<p>While we could request exceptions for every single one, this would require updating the app every time we enable a new HTTP site through our back-end. I was not looking forward to this, and I wondered how many others were similarly dreading the transition.<p>On a related note, does anyone know how Firefox, Chrome, or other browsers are handling this? Don't they need to have a universal exception for HTTP, which is not supposed to be allowed under the new rule?
I don't get why they're delaying this. My understanding was that fully disabling ATS would require a justification. That makes sense.<p>It's annoying to have to audit your apps and enumerate the endpoints, but as long as Apple didn't require justification for explicit domain exceptions, everything should've been fine.
How would ATS affect apps which don't just talk to one server of the developer of that app? What if an app should talk directly over wifi to a device in your local home network via HTTP? Or to a system that each company who buys it hosts on their own and in the app the customer has to supply that hostname or IP in order to connect?<p>Would ATS have enforced that there could only be a few centralized cloud servers?<p>And can I simply bypass ATS by linking in curl+openssl?<p>Are iOS apps even allowed to open raw TCP sockets?
Apple's own services make extensive use of plaintext HTTP. Even if they're only doing so in ways that are safe (due to other application layer encryption mechanisms like in iMessage) it's hypocritical for them to enforce a requirement on 3rd parties that they themselves cannot meet.
Speaking of Transport Security, last night I got bitten by the removal of OpenSSL headers in Xcode in favor of their own "-framework security" aka Secure Transport.
Friend of mine works at a really REALLY big bank. Works on their iOS app and their SSL cert is long expired.<p>The iOS client does certificate pinning, so it isn't a huge security concern (although revocation would be a nightmare), but it does not surprise me that people are afraid of supporting TLS only for their apps.
I expect the likes of Facebook, Microsoft to already be ATS-ready. But it has been my experience that Unreal Engine 4 and Unity are not. Its probably the big game makers of the App Store that are influencing this delay.