‹
›

Getting Ready for ATS Enforcement in 2017

Edit: This blog post was updated on the 20th of October 2016 to take into account recent changes made by Apple to App Transport Security and how ATS exemptions work; for example, the third-party domain exemptions were removed from the documentation. Apple also released additional details in regards to the App Store review process and potential rejections due to ATS exemptions that are described here.

Edit 2: On the 21st of December 2016, Apple announced on its developer portal that the January 1st deadline “has been extended and [Apple] will provide another update when a new deadline is confirmed”. We will update this blog post with the new ATS deadline as soon as Apple announces it.

App Transport Security was introduced last year with iOS 9 as a security mechanism that blocks “unprotected” connections initiated by Apps, ie. connections that do not use HTTPS with the strongest TLS version and cipher suites.

Because switching servers to the strongest TLS configuration takes time, Apple also allowed developers to disable some or all of ATS’ requirements using various exemption keys to be added to the App’s Info.plist. Exemptions could be set for specific domains and/or specific ATS requirements (for example to allow TLS 1.0 instead of 1.2, or to re-enable plaintext HTTP connections).

ATS Enforcement in 2017

This year at WWDC, Apple announced that Apps and their servers will be required to be ATS-compliant by January 2017 or App releases will be blocked when pushed to the App Store. They specified three ATS exemptions that will trigger a rejection, unless a valid justification is supplied:

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

Hence and to avoid a rejection during the Apple App Store review process, care must be taken when building the App’s ATS policy, in order to avoid using blacklisted exemptions, or using such exemptions in a way that can be justified to the App Store review team.

There are mainly three different use cases to consider when building the ATS policy:

  • Servers under the developer team’s control that the App connects to.
  • Third-party servers that the App connects to, for example via connections initiated by SDKs.
  • Webviews displaying arbitrary websites to provide a browser-like functionality.

Servers Under the Developer’s Control

For App servers under the development team’s control (ie. not third-party servers) update the servers’ configuration to support HTTPS with TLS 1.2.

Then, remove any blacklisted exemption (NSAllowsArbitraryLoads, NSExceptionAllowsInsecureHTTPLoads and NSExceptionMinimumTLSVersion) from the App’s Info.plist and validate that the App can properly connect to its server endpoints on iOS 9+ devices.

Other ATS exemptions (such as NSExceptionRequiresForwardSecrecy) will not trigger an App Store rejection and, for now, can be left enabled if needed.

Third-Party Servers

For third-party servers that the App connects to, any ATS exemption can be used, including domain-specific blacklisted exemptions, as Apple has stated that not having control of the server was a reasonable justification.

Doing so will require identifying the list of third-party servers the App connects to, in order to be able to add the proper domain-specific ATS exemptions to the App.

WebViews Displaying Arbitrary Websites

For UIWebView and WKWebView webviews within the App that are used to display arbitrary websites (to provide a browser-like functionality), a well-defined list of third-party servers the App connects to cannot be built. Hence, Apple has provided two possible solutions for this specific use case.

A new NSAllowsArbitraryLoadsInWebContent ATS exemption introduced in iOS 10 can be used to disable ATS in all of the App’s webviews. Because this exemption will only work on iOS 10 devices, Apple has also introduced a new behavior in order to allow disabling ATS in webviews on iOS 9 devices: when combining NSAllowsArbitraryLoadsInWebContent with NSAllowsArbitraryLoads, the latter exemption will be ignored on iOS 10. Even though NSAllowsArbitraryLoads will trigger a deeper App review, using these two exemptions together for the webview use-case will be a reasonable justification, according to Apple statements on the developer forums.

However, a better, future-proof approach for displaying arbitrary websites is to leverage the SFSafariViewController introduced in iOS 9, which was specifically designed for this purpose. As mentioned in the Apple documentation:

“Use the SFSafariViewController class if your app lets users view websites from anywhere on the Internet. Use the WKWebView class if your app customizes, interacts with, or controls the display of web content.”

Specifically, the tradeoffs when using SFSafariViewController are the following:

  • ATS is disabled, allowing any website to be browsed regardless of the site’s HTTPS configuration.
  • Cookies and website data is shared with Safari, for example allowing the user to stay authenticated in websites accessed from your App.
  • App developers has very little control on the overall navigation experience compared to WKWebView.

When possible SFSafariViewController should be leveraged in order to display third-party websites within the App.

Conclusion

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.

For more information, Apple added a section specifically about ATS and the App Store review process on the documentation website, a few weeks after the WWDC presentation.

Future ATS Requirements

For now, the NSExceptionRequiresForwardSecrecy key will not trigger a rejection, but this will most likely change next year. Hence, support for forward secrecy should be deployed on App servers in order to get rid of this ATS exemption.

Also, in the “What’s new in Security” WWDC presentation, Apple alluded to future requirements for ATS, potentially to be introduced next year:

  • SHA-1-signed certificates should no longer be used, and they are already getting blocked in web browsers.
  • 3DES TLS cipher suites, which are only needed for Windows XP compatibility, should be disabled.

During the presentation, Apple also heavily mentioned Certificate Transparency and OCSP Stapling as technologies that developers should start deploying on their App servers.

Alban Diquet - 14 Aug 2016 at 20:02