Apple’s App Transport Security (or simply ATS) is a networking security feature that forces an app to use an HTTPS web services connection instead of an HTTP. Apple added ATS as an optional feature with the introduction of iOS9 in 2015: developers were still allowed to switch it off. However, at WWDC 2016 Apple announced that starting from 2017 the feature will be mandatory for all apps submitted to App Store.
In this article, we are going to speak a little more about the App Transportation Security feature, its role in iOS app development, and learn how to add Domain Exceptions considering the new ATS requirements.
A bit more about ATS and its requirements
App Transport Security is basically a set of rules that ensure iOS, macOS, watchOS, and tvOS apps and app extensions connect to web services they work with using secure connection protocols. This improves users’ privacy and integrity of their data and safeguards it from various malicious parties.
By configuring the NSAppTransportSecurity key’s value in your app’s Info.plist file, you can configure your network connections’ security in a different of ways.
You can:
- add exceptions for insecure communication with particular servers;
- disable ATS protection for web views or media, while still using the feature to protect other data in your app;
- enable Certificate Transparency and other new security features.
Currently, ATS requires your app to connect to servers that:
- support the Transport Layer Security (TLS) protocol version 1.2 or later;
- use AES-128 encryption standard and SHA-2-signed certificates;
- provide Forward Secrecy protocols.
However, since Forward Secrecy protocols aren’t used by the majority of servers yet, Apple can accept this as a reasonable justification for including ATS in your app even if the servers it connects with doesn't provide Forward Secrecy.
Among other reasons that can justify including ATS in your app without meeting all requirements are:
- the server is not fully ATS compatible;
- you use a third-party service or SDK that does not support ATS at the moment;
- you don’t have the time or the resources to add the required functionality yet.
However, these exceptions are temporary: Apple just gives developers some time to get ready to use ATS as a mandatory with future updates. And the first requirements update is coming real soon.
The new requirements
Since January 1, 2017, the ATS feature will be mandatory for all apps on App Store and for the servers they connect with. If you don’t want your app to be rejected from App Store, you must turn on and configure ATS according to the new requirements.
Here are three cases when an exempted ATS will lead to an app rejection from app store:
- NSAllowsArbitraryLoads, which disables ATS for all domains. ATS can be re-enabled for specific domains by using an exception domain dictionary.
- NSExceptionAllowsInsecureHTTPLoads, which disables ATS for a single domain, to allow insecure HTTP loads to that domain.
- NSExceptionMinimumTLSVersion, which enables support for TLS versions that are older than 1.2 for a specific domain.
Other ATS exemptions such as, for example, NSExceptionRequiresForwardSecrecy can be enabled and won’t trigger an App Store rejection.
However, the three blacklisted exemptions mentioned above can lead to rejection only in case the servers an app connects to are under the developer’s control. For third-party servers, on the other hand, all ATS exemptions can be used: according to Apple, using a server you don’t have control over is a reasonable excuse for developers to use the exemptions.
To do this, you will need to identify all third-party servers your app connects to and to add the ATS exemptions specific to the domains.
Why Apple now enforces ATS
Unlike web browsers that designate the type (HTTP or HTTPS) of connection they use, mobile apps don’t let users know whether they use regular or secure web connection.
The initial implementation of ATS as an optional feature was surely only the first step towards increasing mobile app’s security. Now as app developers got to know the new networking security feature, Apple takes one more step closer to ensuring secure web connection within their products.
How to add Domain Exceptions
Here’s what you do to add a third-party domain as an exception for your ATS.
Add the NSExceptionDomains key to the NSAppTransportSecurity dictionary of your app’s Info.plist file. The key’s value is a dictionary which contains keys describing domain exceptions:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<false/>
<key>NSExceptionDomains</key>
<dict>
<key>agilie.com</key>
<dict>
<key>NSIncludesSubdomains</key>
<true/>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
</dict>
</dict>
</dict>Here, we enable ATS and set a domain exception for agilie.com. The NSIncludesSubdomains key means we include all subdomains of this domain as exceptions, too. The NSExceptionAllowsInsecureHTTPLoads key allows the non-HTTPS requests for the domain and its subdomains.
Setting the value of the NSAllowsArbitraryLoads key to true applies the ATS rules to the domain and subdomains, while they will remain exceptions.
You can also add multiple domain exceptions at a time and apply the exceptions not only to the HTTPS protocol network requests but also to the configuration of the server your app connects to.
Here’s an example:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<false/>
<key>NSExceptionDomains</key>
<dict>
<key>anotherdomain.com</key>
<dict>
<key>NSIncludesSubdomains</key>
<true/>
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.0</string>
</dict>
<key>onemoredomain.com</key>
<dict>
<key>NSExceptionRequiresForwardSecrecy</key>
<false/>
</dict>
<key>agilie.com</key>
<dict>
<key>NSIncludesSubdomains</key>
<true/>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<true/>
</dict>
</dict>
</dict>Now you know how to add domain exceptions. But will it be possible with the further ATS updates? Let’s sum up what we know to expect so far.
The future of ATS
While the NSExceptionRequiresForwardSecrecy key won’t lead to app rejection from App Store, this will probably change with the future ATS requirements updates. This is likely to happen as soon as more servers will provide the Forward Secrecy protocols.
Some hints were given during Apple’s What’s New in Security presentation at WWDC 2016. Here’s what you as an iOS developer should take into account next year:
- The SHA-1-signed certificates won’t be used since they are to be blocked by Google.
- The 3DES TLS cipher suites are better to be disabled since they’re only needed for the compatibility with the obsolete Windows XP.
- You should start deploying the Certificate Transparency and OCSP Stapling (aka TLS Certificate Status Request) technologies to your app servers.
Luckily, Apple understands that it’s impossible to cut all insecure connections at a time, and they are ready to make exceptions for those who can’t meet all the requirements.
But don’t rely on these exceptions heavily - their main purpose is to get you ready to use ATS as a mandatory feature in the nearest future. Apple wants you to provide greater security to your app and to people who use it, so complying with the new ATS requirements will help you build trust with your users and - ultimately - provide better services.
