
Apple Delays iOS SSL Requirement Indefinitely - mark-ruwt
https://developer.apple.com/news/?id=12212016b
======
cyb3rl0l
What was supposed to happen on January 1st:
[https://datatheorem.github.io/ios/ssl/2016/08/14/ats-
enforce...](https://datatheorem.github.io/ios/ssl/2016/08/14/ats-
enforced-2017/) .

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

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

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

~~~
rgsh22
> Why did they back up off SSL?

Go try and buy something on [https://apple.com](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...

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

~~~
brazzledazzle
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.

~~~
tuxracer
Yeah but the checkout button on the insecure cart page could be changed so
that it instead points to [http://www.apple-payment.com/..](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.

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

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

~~~
mark-ruwt
Indefinitely means "for an unlimited or unspecified period of time".

[http://www.dictionary.com/browse/indefinitely](http://www.dictionary.com/browse/indefinitely)

~~~
UnoriginalGuy
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.

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

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

~~~
wilg
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.

~~~
0xFFC
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.

~~~
dogma1138
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.

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

~~~
SunboX
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.

~~~
mrpippy
There are allowances made for local networking.

From the Info.plist key reference
([https://developer.apple.com/library/content/documentation/Ge...](https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW54)):

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.

~~~
seanalltogether
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.

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

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

~~~
cyb3rl0l
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.

~~~
gnicholas
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.

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

~~~
gilgoomesh
> 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.

~~~
valarauca1
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.

~~~
gilgoomesh
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.

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

~~~
JamesB7
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.

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

~~~
comex
> 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.

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

~~~
azinman2
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.

~~~
bgentry
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

~~~
willstrafach
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.

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

~~~
X-Istence
Apple has had deprecated on the OpenSSL headers for a couple of releases
now...

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

~~~
willstrafach
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.

------
orasis
I think at least NSURLSession is forcing HTTPS currently.

~~~
orbitur
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.

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

~~~
Ambroos
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.

~~~
orbitur
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.

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

