Is Your Application Ready for App Transport Security (ATS)?

Beginning January 2017, Apple will require iOS, tvOS and watchOS developers to ensure HTTPS connections are used over HTTP, using the App Transport Security, or ATS for short. This security protocol has been available since iOS 9 but until now, hasn’t been a mandatory requirement for new App Store submissions.

UPDATE: Apple has extended the deadline of the ATS requirement. Read the press release note. The new deadline will be confirmed in the future.

Overview of the App Transport Security

ATS is a security protocol that forces apps to use HTTPS over HTTP and defines concrete exceptions for HTTP usage.

The ATS configuration is defined inside the
YourApp-Info.plist file. The default configuration (none), means the app can only use HTTPS. The most common configurations are listed below:

NSAllowsArbitraryLoads (boolean): Enables arbitrary loads in HTTP. This will no longer be allowed in production apps.

NSAllowsArbitraryLoadsInWebContent (boolean): Enables arbitrary loads in web views. This may be very useful if your app loads web view content that might link to HTTP pages.

NSExceptionDomains (dictionary): List of exception domains. Each exception will be configured independently as illustrated in the image below.

This image can be used as an example of an ATS configuration that enables arbitrary loads for media and web content, and adds a specific exception domain for a minimum TLS version 1.2, without a transparency certificate.

You must be aware that by adding exceptions or allowing arbitrary loads for media or web content, Apple might reject your binaries if you don’t explain in detail why it’s required.

Validating Your App

When it comes to updating your app, you may be tempted to think it’s as simple as changing the HTTP scheme to HTTPS in your servers. However, you should take third party SDKs into consideration, alongside web view redirects that may be using plain HTTP requests. First of all, you’ll need to find a way to list all requests to find out which are still using HTTP.

1. Enabling Network Diagnostics Logs

Apple provides an option to enable network logs for any kind of data transactions between the app and an external server. In order to enable the logs, add the following code to your application’s delegate.

This is the file where the system is logging all network usage, ALL of it. If your app is loading lots of images or videos, all the raw data will be stored in that document. Therefore, it’s not a good idea to always have logs enabled, only when debugging it.

2. Test the App

It’s now time to test your app, try to run all use cases and corner cases, taking any third-party SDKs the app may have into consideration. Any network activity will be logged into the network diagnostics file and our goal is to try to cover as many different types of connections as possible.

3. Check the Logs

Next, you need to analyse the network diagnostics log file. Look for network requests that failed with an error domain
kCFErrorDomainCFNetwork and an error code of
-1022.

The easiest way to search for these errors is using a Terminal console and the following command:

1

cat<file>|grep-B1-A0'Error Domain=kCFErrorDomainCFNetwork Code=-1022'

This command will look for all errors and print out the line where the scheme://host is located. It his highly recommended to use this approach rather opening the file itself, as it may contain thousands of lines.

It’s going to be easier to run this analysis when using the iOS simulator over a real device. However, it is also possible to download the log file from an iOS device and analyse it after.

4. Fix and Repeat Until No More Errors

After updating your services and sources to use HTTPS or by adding exceptions into the
info.plist file, it’s time repeat the testing process as new issues may have risen after fixing the previous ones. Repeat the process until no more issues are found.

5. Disable Network Diagnostics Logs

Finally, remove the line of code we introduced above that enables network diagnostics. Leaving this code in a production app will result in users storing raw data in their devices, consuming lots of memory space and may even create a security breach.

Don’t Be Mad at Apple

At Mobile Jazz, we take security very seriously. We always ensure our projects use HTTPS, SSL certificate signing and any additional appropriate security layers. You should also be doing the same for your products, as Apple are just trying to enforce good engineering and secure practices. So, don’t be mad at Apple, simply upgrade your apps to the new security standards.

Starting with mathematics, continuing with a computer science masters degree and working on mobile development during the past 8 years, Joan is a proficient software engineer. Motivated by great projects and an awesome team, Joan is currently leading the mobile team at Mobile Jazz and enjoying the MJ philosophy at its best.