Shipping an App With App Transport Security

Tim Ekl (tweet):

This article is aimed at a different purpose: to look at the different speed bumps that can show up while building an app alongside ATS, and to explain how to get around them. There are lots of great little tricks that have only cropped up in OS X release notes or on Stack Overflow, or that can only be discovered by building a sample app.

[…]

With this more extensive ATS dictionary in our app’s Info.plist, we turn the “allows insecure HTTP loads” flag back off for the example.com domain and all its subdomains. When our app makes any connection to a host in that domain, then, we’ll be receiving the full protection of ATS.

This exception mechanism can handle even more complex scenarios. For example, consider what might happen if most servers in example.com were correctly secured with HTTPS, but one server – say, insecure.example.com – wasn’t yet fully ATS-compatible. We can handle this by defining another more specific exception for just that host[…]

[…]

In both of these error cases, we can set the environment variable CFNETWORK_DIAGNOSTICS to 1 in order to get more information on the console about the failure. After turning this variable on in our app’s scheme, you’ll notice a new log line with a path to a diagnostic file; this file, in turn, is filled with information about all the actions the CFNetwork layer is taking on behalf of your app’s networking code.

[…]

If you have access to an OS X machine running 10.11 or later, the command-line utility nscurl provides some basic ATS debugging capabilities.

Tristan Emrich:

While Google remains committed to industry-wide adoption of HTTPS, there isn’t always full compliance on third party ad networks and custom creative code served via our systems. To ensure ads continue to serve on iOS9 devices for developers transitioning to HTTPS, the recommended short term fix is to add an exception that allows HTTP requests to succeed and non-secure content to load successfully.

Note that this allows all HTTP requests to succeed, not just ones pertaining to Google ads.

Nick Heer:

So in a year where malware-laden ads are becoming increasingly frequent, Google’s response is not to convert their ad network to HTTPS, but rather to tell developers to reduce the security of their apps.

Google update:

To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful.

Previously: App Transport Security.

Update (2015-09-23): Keith Harrison:

So did Apple change the ATS policy between the public and GM releases? It sure seems like it. Luckily I have the CFNetwork debug logs from the device for both the failing GM test and the successful public release test. I have filed a bug (22763438) with Apple to see if they can explain what is happening. If I learn something that changes how we need to use ATS I will update here.

[…]

A clue to what might be happening is in this Apple Developer forum thread. It seems there is/was a bug where setting NSExceptionRequiresForwardSecrecy had a side effect of relaxing the SHA-256 signature requirement. Maybe Apple has relaxed the requirement so as not to break any Apps that now depend on the undocumented side effect of disabling forward secrecy.

Update (2015-10-13): Tim Ekl:

ATS requirements apply at every step of a redirect. If you have a server rewriting URLs or otherwise redirecting to a different location, both that redirector and the new destination must meet ATS’s requirements.

It’s not possible to add dynamic ATS exceptions. Every exception must be given in your app’s Info.plist up front.

Playgrounds and SFSafariViewController both ignore ATS. The latter can be a great way to show user-generated Web content, such as in a social media app.

Advertising Debugging Google iOS iOS 9 Mac Mac OS X 10.11 El Capitan Networking Privacy Security SSL/TLS Web

4 Comments RSS · Twitter

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ