Apple Delays iOS SSL Requirement Indefinitely | Hacker News Reader

Apple Delays iOS SSL Requirement Indefinitely

developer.apple.com

160 pointsmark-ruwt76 comments

What was supposed to happen on January 1st: https://datatheorem.github.io/ios/ssl/2016/08/14/ats-enforce... .

"The overall approach the App Store review team will take when it comes to ATS exemptions was summed up on the Apple developer forums:

    “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.”

Hence, for a given App going through the App Store review process:

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

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

* Lastly, a policy that will definitely trigger a rejection, as stated by Apple, is to have NSAllowsArbitraryLoads enabled with no additional ATS settings. "

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.

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?

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.

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.

> Why did they back up off SSL?

Go try and buy something on https://apple.com - you will once you go to view your cart you will be redirected to plain vanilla HTTP. There is no way around this. If they can't get their own SSL support in order...

Why is there no way around this? This is surprising to me and I'm super curious.

The exchange of payment or authentication information is undoubtedly done over TLS so it's probably just not a priority. That said there seems to be some obvious security issues with it since a bad actor could, as far as I know, inject malicious javascript in the vanilla http page to do all kinds of fun stuff.

Yeah but the checkout button on the insecure cart page could be changed so that it instead points to http://www.apple-payment.com/... or any random malicious "checkout" page which then steals your CC. They've compromised the security of credit card details users will at some point enter by doing this. It's insane if that isn't a priority.

It also exposes all of your cookies for apple.com since not a single cookie is marked secure/HTTPS only.

If I had to give them the benefit of the doubt, I'd guess that they feel that SSL has failed at fulfilling its intended purpose, and that they're working on a "superior" alternative which they plan to use for themselves and force all developers for their platforms to also use, in an attempt to encourage it to spread and supersede SSL.

>I mean, these guys forced every app to be able to handle IPV6-only network operations last year.

That's easy to answer. The US government has an IPv6 mandate. They have no such SSL mandate.

The US gov does mandate that products support IPv6, but they don't mandate that everything can work on v6-only networks.

The mandate comes from mobile carriers, some of whom desperately want to run networks where phones only get v6 addresses, and v4 traffic is tunneled through DNS64/NAT64.

And you don't think the government runs their own mobile networks in war zones? They definitely aren't relying on Zain.

While I agree with everything you said, here's an example of forced SSL being very hard to deal with.

Decentralized platform, needs to be connected to nodes. Each node can't get an SSL cert because we can't force everyone on a blockchain to get a domain name. It doesn't matter that there's SSL anyway because everything's signed by the server anyway. The data the client sends is also public, so the worst that can happen is an attacker blocks a transaction. This can also happen with SSL.

We could just distribute a cert with the node and hardcode it into our app, but then there's no point of SSL, we just published our private key.

Yes, this is kinda edge case.

The title at the time of posting reads: "Apple Delays iOS SSL Requirement Indefinitely."

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

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.

You should email this stuff to the mods since they don't read every post. It's definitely a confusing title.

Indefinitely means "for an unlimited or unspecified period of time".

http://www.dictionary.com/browse/indefinitely

I know. Which is why my post reads:

> "Indefinitely" while technically accurate also implies "unlimited period of time."

It has two meanings. But is more often used to mean unlimited period of time.

Yep I read the title and assumed that the first meaning was meant.

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.

Having a configurable option to disable a security setting is a pretty bad idea. Users who don't know anything about security will just disable it forever the first time an app tells them to.

I think you missed the idea, It could be temporary thing for a while, after a year or two and with continues beforehand notification, apple could disable non-secure connection apps definitely.

kind of like transition period.

No there shouldn't be a configurable setting; giving users a choice just creates problems; giving developers a way out just delays implementation.

As long as there is a way for an App to make non-SSL connection you'll have to run a non-SSL enabled endpoint; which in effect can put users at risk even if they haven't configured their own devices/apps to use it.

> Having a configurable option to disable a security setting is a pretty bad idea.

I think the proposal was to have a configurable option to enable an extra security lockdown, which would remain disabled by default.

At which point, it essentially becomes a "break some of my apps in confusing and inexplicable ways" button.

Related reading: http://limi.net/checkboxes-that-kill

  to get this app to work, run:
  $ sudo setenforce 0
  problems solved!

Not having a configurable option to disable a security setting that's getting in the way of my ability to do what I want on my computer is a worse idea.

IMHO, it is not Apple's style to make such things configurable.

No, the original plan was only to apply the rule to newly updated apps anyway.

Maybe, but the "indefinite" thing is stupid. Make it 3 years if you must, but do set a deadline. Making it indefinite just means a good portion of the app developers will never even give this a second thought anymore.

There's no 'indefinite' and there will be a new deadline - that's right there in the linked thing.

This was going to be an App Store certification change, requiring newly-submitted/updated apps that broadly opt-out of ATS to provide a justification. Existing approved apps would continue to run the same.

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.

Think of IoT Devices. For example, Sony's NEX Cameras have a build in HotSpot. You connect your phone to it and you have remote control to your camera. This has no HTTPS by now. Apple would break all those remote control apps. And it can't be fixed by releasing a new app version, because you also have to update the cameras.

There are allowances made for local networking.

From the Info.plist key reference (https://developer.apple.com/library/content/documentation/Ge...):

App Transport Security (ATS) applies only to connections made to public host names. The system does not provide ATS protection to connections made to:

* Internet protocol (IP) addresses

* Unqualified host names

* Local hosts employing the .local top-level domain (TLD)

To connect to an unqualified host name or to a .local domain, you must set the value of the NSAllowsLocalNetworking key to YES.

That's assuming you're using bonjour (zero config). I have 2 clients with thousands of in home devices which are using NetBios to resolve a local ip address and directly connecting over http. I imagine there are many other hardware vendors still using this method out there.

Sounds like the HTTP connection is being made to an IP address, in which case you should be fine.

It can't even be fixed then because TLS certs aren't possible for LAN connections (or at least not validate-able, which means the same thing).

TLS certs are about to be possible for LAN connections with Beame.io's open source SDK, though

A good start would be a warning about insecure connections being made by the app.

They had a method for whitelisting vanilla http domains in the app plists. It wasnt going to eliminate http. It was going to push general app transport to TLS by default.

Apple seems to have wildly varying execution. Some things they do are great. Other times their behavior is shockingly erratic.

Principally? Reliance on cloud service origins without TLS support. Amazon still has some from acquisitions, for example.

I think you also have to register with some US government body to obtain crypto export licenses yearly. Even if the app just uses the iOS https connection classes!

No you don't.

It used to be like that, but it seems like this was changed in the last month?! http://stackoverflow.com/a/40919650

For all the downvoters on my parent post: This blog from last year said something else: https://pupeno.com/2015/12/15/legally-submit-app-apples-app-...

Edit: Downvote me all you want, but the OP asked why people just didn't implement HTTPS and I have first hand knowledge of several apps that chose to not implement HTTPS because the legal work required around crypto export licenses was too much to be worth it.

It was always exempt because you weren't shipping your own crypto implementation. Apple has to comply when shipping iOS. Those apps were not shipping HTTPS for a non-reason. This recent change only made the wording clearer in iTunes Connect.

The uncertainty around phrasing like "uses encryption" certainly would require spending expensive lawyer hours to ensure the app would be in the clear. Certainly not a "non-reason".

I've spent time with lawyers on specifically this topic. It is about who is distributing the crypto code. There is also an exemption for open source crypto code. On iOS you definitely do not need to register your app if it is just using the built in HTTPS functionality. Hire your own lawyers if you're really worried about it though.

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.

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.

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?

Apple introduced an ATS exemption specifically designed for the browse-to-any-website-in-a-webview use case. You can also use the Safari ViewController which doesn't enforce ATS (by design). Hence you don't need to list all these third party domains in your Info.plist.

Unfortunately, the Safari ViewController doesn't do everything that the old UIWebView and WKWebView did. I think in our case we needed to be able to increment the cache size (to be compatible with Kindle Cloud reader), and this was only available on UIWebView. I could be mistaken here, and regardless I hope the Safari ViewController is updated to support this feature.

Forgive me if I've misused terminology here—I'm the non-technical founder—so my understanding of why we couldn't use the Safari WebView (which I assume is the same or closely related to what you referenced) is a bit fuzzy. All I know for sure was that our dev team was not looking forward to pleading for ATS exceptions.

The Safari view controller is a very different beast to UI/WKWebView, though - if you want to do any kind of integration between the webview and app you're pretty much locked out.

I don't get why they're delaying this. My understanding was that fully disabling ATS would require a justification. That makes sense.

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.

> but as long as Apple didn't require justification for explicit domain exceptions

The previous plan was they they were going to require justification for every domain exception.

Further, they were going to require justification if you were already using HTTP Live Streaming... Apple's own protocol which is written to use AES encrypted segments over plain HTTP.

They were going to require justification for peer connections that have to jump through hoops to get URLSession recognize their self-signed certificates. This one in particular is still affecting one of my apps. It's not always possible to force peer certificates to be accepted, making HTTPS between peers very difficult (seemingly impossible) at times.

I'm not saying that these things can't be done but I think Apple underestimated the number of systems affected and the justifications and reasons involved. HTTPS is fundamentally not "everywhere", despite its prevalence in larger systems.

You really shouldn't do HTTPS if you can't complete the chain of trust with a peer.

If one is doing some multi-cast multi-tenant swarm stuff... why is the data private? It seems like a lot of people have access.

In my case, your peers are your friends. You use a pairing code (part of the SHA256 fingerprint) to accept the certificate (so you need to see the other person's screen and have agreement with the fingerprint) and then you can use indefinitely. It's great until the whole connection fails because some element in the system works with Certificate Authority certs-only – issues we're still working on and certainly won't be finished by Jan 1.

The finger print is public. There is literally zero security in this system anyone can hijack it

Public keys are public. Just because you don't understand cryptography doesn't make a system bad.

There's nothing magical about certificate authorities. There are many ways to establish secure connections without them.

That's not quite right. You will still have to justify every domain exception.

> By the end of 2016, when your apps communicate with your own server back ends, they must do so using a secure TLS channel using TLS 1.2, unless the data being communicated is bulk data such as media streaming and data that’s already encrypted.

https://nakedsecurity.sophos.com/2016/06/17/apple-ios-to-req...

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?

Would ATS have enforced that there could only be a few centralized cloud servers?

And can I simply bypass ATS by linking in curl+openssl?

Are iOS apps even allowed to open raw TCP sockets?

> 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?

iOS 10 adds the key NSAllowsLocalNetworking which disables ATS for "connections to unqualified domains and to .local domains". So this can continue to work.

However, treating local networks as secure isn't generally a good design! If the home network has an open Wi-Fi hotspot, or a WPA hotspot with WPS PIN enabled or where the attacker knows or can bruteforce the password (and in many other cases), it is possible to sniff other users' traffic. Instead of using an unencrypted connection, whether HTTP or otherwise, you should design the initial pairing process between the app and the device to set up encryption keys. For HTTPS this can be in the form of having the device generate a self-signed certificate and send it to the app to use as a custom root. You need some sort of pairing or setup process anyway for the device to know how to connect to the user's network, so you might as well do security properly.

> 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?

In that case you should probably just require the companies to have a domain and a certificate for it; build in Let's Encrypt support if you want.

> And can I simply bypass ATS by linking in curl+openssl?

From a technical perspective, yes, though I can't say whether Apple would reject an app because of it.

> Are iOS apps even allowed to open raw TCP sockets?

Yes.

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.

Can you give an example of this? I've been using charles proxy for various tasks a bunch on my iPhone, and so far it seems that all the calls to Apple that I've noticed are HTTPS.

Here's a partial list from my Little Snitch config on macOS Sierra:

- com.apple.geod.xpc tried to establish a connection to gspe19.ls.apple.com on port 80

- App Store / softwareupdated uses port 80 to download updates from swcdn.apple.com

- helpd uses port 80 to fetch help docs from the web

- IMTransferAgent tried to establish a connection to ussjc.ce.apple-dns.net on port 80. This is used by Messages.app when picture messages are received.

- iTunes uses port 80 all over the place to fetch content from the mzstatic CDN and others

- nsurlsessiond uses port 80 to fetch from apple-dns.net, blobstore.apple.com, icloud-content.com, aaplimg.com

- photolibraryd via com.apple.photomoments.xpc tried to establish a connection to gspe21.ls.apple.com on port 80

- Photos Agent tried to establish a connection to s3-w-a.us-west-2.amazonaws.com on port 80

- storeaccountd tried to establish a connection to sandbox.itunes-apple.com.akadns.net on port 80

- storedownloadd tried to establish a connection to osxapps.itunes.apple.com on port 80

- SpotlightNetHelper tried to establish a connection to wu-calculator.apple.com on port 80

FYI, some of those are due to content being non-secret + already digitally signed and wanting to assure they can be served from the "Cache Server" within enterprises to help speeds.

Use little snitch on your mac OS computer, you'll see all sorts of port 80 connections to things like mzstatic.com and so on.

Oh. That's the platform they don't really care about.

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.

Apple has had deprecated on the OpenSSL headers for a couple of releases now...

Friend of mine works at a really REALLY big bank. Works on their iOS app and their SSL cert is long expired.

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.

That is fine though. ATS just ensures you are using TLS v1.2 and such, but doesn't enforce expiration / CRL / trusted roots / etc. That would be done in app, usually using default built-in frameworks but sometimes with custom logic to do things like certificate pinning.

I think at least NSURLSession is forcing HTTPS currently.

You can disable that by adding a key to your Info.plist.

They mean at the App Store submission point. In January, they were going to start rejecting apps that didn't provide a justification for completely disabling ATS.

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.

Try media companies. We have been working to make our television companion apps ATS-compliant. All our advertising / analytics / streaming endpoints had to be HTTPS. We ended up with a list of dozens of domains from over 10 external companies (mostly related to video ads / streams) that still had to be made available over HTTPS, or we'd have to get exemptions for those domains.

We're still going on with our efforts to make everything go over HTTPS always, but this does take the pressure off a little. We were really fearing not being able to submit updates in early 2017 because of ATS.

We have similar clients. They insist every app must have at least 5 different analytics/ad providers and god knows what else.

I was honestly kinda looking forward to January because it would force them to re-evaluate some of the shittier providers so they could get app updates out.

In other news, rumours report that the next iMac will reintroduce the floppy drive

Reply on news.ycombinator.com