App Transport Security REQUIRED January 2017

I am all for secure communications, but there are some times when it is simply not possible. I have an app that communicates with an physical satellite modem. That satelite modem is local to the wifi network and only exposes an HTTP connection. There is no way to connect to it securely. Is this app simply no longer possible?

I agree. I understand that security is important, but there are far too many services that still use HTTP. I have an app that pulls images from NOAA over an HTTP connection. I don't see them switching to HTTPS anytime soon. Without an exception my app would be useless.

We are in the same situation having an app which is in fact a proxy between web media and local network. A lot of web servers does not impement HTTPS and communications over local network too. It seems our app will be absolutely useless without NSAllowsArbitraryLoads. There must be a procedure/approval for apps like our similar to setting for example Background modes for apps. I am sure a lot of apps are in our situation.

Sturgmeister on the xamarin forums mentioned that Apple (during the keynote) said that they would allow developers to apply for exemptions. I'm hoping that he is correct as in my particular use case, I call a REST API on an embedded board and it would literally be impossible to use SSL on without forcing all of our customers to upgrade at a cost of $5000+ per site.

First up, there have been no changes to the technical behaviour of ATS (other than the addition of

NSAllowsArbitraryLoadsInWebContent

NSRequiresCertificateTransparency

What has changed is that App Review will require “reasonable justification” for most ATS exceptions. 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.

The impact of this will depend on the circumstances of your app. I don’t work for App Review, so I can’t give definitive answers as to what constitutes a “reasonable justification” in their minds. However, I can recommend that you do the following:

• watch the WWDC session where we announced this change (WWDC 2016 Session 706 What’s New in Security) so that you can get a feel for the rationale behind it

• carefully audit your app’s use of HTTP and HTTPS

• construct a minimal ATS exception dictionary

• if you have ATS exceptions, keep notes about your analysis so that you can refer back to them when you need to submit your justification to App Review

Finally, if there are places where ATS has limitations that cause you to specify wider exceptions than one might reasonably expect, file an enhancement request against ATS for more appropriate exceptions. Make sure to note the bug number to use in your justification. And I’d appreciate you posting your bug number here, just for the record.

[I’ve removed the following example because we introduced

NSAllowsLocalNetworking

For example, right now ATS has very poor support for dealing with accessories on the local Wi-Fi. An app that needs to deal with such an accessory may well need to set

NSAllowsArbitraryLoads

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks, Quinn. Your response is very close to what I expected would happen. Anticipating that, I spent all last week with Allow Arbitrary Loads turned off. I had to create a huge list of exception domains in order to enable not only the third party open data APIs I reference, but their corresponding websites for configuration or information. Because NSAllowsArbitraryLoadsInWebContent is not available in iOS 9, I had to inspect and whitelist embedded links, e.g., code.jquery.com. If I didn't, some website controls would either look wrong or not work. That's even ignoring the FB and Twitter links I found.

There just doesn't seem to be a good way to release an app that can work compatibly in both iOS 9 and 10 if it depends on HTTP-only third party APIs and HTTP-only third party websites. I filed an enhancement request under 26976436.

I also submitted 26979531 as a bug report to allow LAN devices that are discovered by SSDP to be accessed using their discovered IP addresses, via HTTP/GET, while still retaining the security to block WAN access.

What happens to apps that are still in the app store by the end of the year that aren't using HTTPS?

Yeah, I concerned this too. I guess they will be work as is, but I'd like to have some confirmation from Apple about this...

You can use https://letsencrypt.org

It is free, stable and used by millions of web sites already.

Requires update every three months which can be automated.

I am testing it for 6 months already. Has been in beta till last month.

Now is out of beta.

You can register as many domains as you need for free.

Filed enhance request 27850892 to relax the Perfect Forward Secrey requirement.

Quoted from the document on the default ATS requirements:

1. The server certificate must meet at least one of the following trust requirements:
2. The negotiated Transport Layer Security version must be TLS 1.2
3. The negotiated TLS connection cipher suite must support forward secrecy (FS) and be one of the following:
4. The leaf server certificate must be signed with one of the following types of key

#3 seems to be Perfect Forward Secrey from nscurl utility output. I am wondering how widespread is perfect forwad secrey being enabled in web sites.

This particularly poses an issue for enterprise customers that the same App might be configured by end users to talk to different servers. For example, customerA's employees download the App from App Store and use it to connect to customerA's servers, and customerB's employees ask the same App to connect to different servers; and worse, the developers who build the App have no idea on those servers' SSL configurations/strengths.

Thanks for providing information.

Best regards,

CV Maker

Clearly this isn't going to work in every scenario, but take a look at this as this will cover most of the scenarios where this will impact, https://www.contradodigital.com/2016/09/01/claim-your-free-ssl-certificates-for-https/ - Lots more technical resources listed at the bottom of the page too for those with the capability to implement theirself.

Thanks Quinn for all the great information. What's the process for determining now whether our 'reasonable justifcation' is in fact reasonable in the App Review teams mind, post-Jan 2017? If we submit an App with a single domain NSExceptionAllowsInsecureHTTPLoads exception for review today, together with our reasonable justification, can we ask for it to be reviewed as if it's post-Jan 2017?

There is already a NSExceptionRequiresForwardSecrecy exception which (I believe) will still be allowed post Jan-2017 (needs confirmation).

BTW over 50% of sites have PFS for modern browsers. If you scroll down here you can see https://www.trustworthyinternet.org/ssl-pulse/.