Network Security Changes Coming to iOS

Changes to App Transport Security

Last year, with iOS 9, Apple introduced App Transport Security; an enforcement of best practices for encrypted networking. By default, App Transport security requires the following:

• NSURLSession and NSURLConnection traffic be encrypted
• AES-128 or better and SHA-2 used for certificates
• TLS v1.2 or higher
• Perfect forward secrecy

In other words, it requires that your app keep your users’ network traffic reasonably protected.

While enabled by default in iOS 9, Apple recognized that may developers don’t control their backends, and included the ability to set exceptions for App Transport Security. The problem is many developers went right for the NSAllowsArbitraryLoads key, which disables ATS entirely, then never bothered to re-visit their configuration to get everything working nice and securely.

Last week, at WWDC 2016, Apple announced that beginning January 1, 2017, App Transport Security will be required (this topic starts about 1m20s into the What’s New In Security session). You should really watch the talk for the exact details from Apple, but in short, all of your app’s traffic needs to be secured with HTTPS and will need to use TLS v1.2 or higher.

Apple will still allow some exceptions, but the rules will be much less relaxed than they have been:

• Most exceptions will now need to be justified to Apple. NSAllowsArbitraryLoads, NSExceptionAllowsInsecureHTTPLoads, and NSExceptionMinimumTLSVersion will all require a reasonable justification for use.
• NSExceptionRequiresForwardSecrecy will not require a justification for now. If used, this exception will be granted automatic approval. Presumably this will change down the road as forward secrecy becomes more widely spread.
• Streaming media using AVFoundation is exempt, but Apple says you should still encrypt with TLS if possible.
• Content loaded inside of WKWebView does not have to be encrypted. This requires specifying the NSAllowsArbitraryLoadsInWebContent key as true in your Info.plist.
• Data that is already encrypted does not have to go over HTTPS.

The specific example Apple uses in the talk for still needing exceptions is communicating with a third-party server where you can’t control their cipher suites. Even if this is your situation, it sounds like needing to justify exceptions may slow review time, so it’s probably worth talking to any third parties you work with to ensure they can meet ATS requirements.

If the reason you haven’t supported ATS yet is because it seemed like too much work, now’s the time to start making changes. One of the difficulties you may face implementing ATS is diagnosing failures. On the surface, you’ll likely just see data fail to load in your app with no real indication as to why. What I’ve found most useful is the nscurl --ats-diagnostics https://example.com command. It will test different ATS configurations against the specified domain and report back showing which scenarios pass and which fail. The failed scenarios will make it much more clear what you need to change on your server to support ATS. Tim Ekl has some more helpful info about debugging in this blog post on ATS from last year.

If the reason you don’t yet support ATS is the cost or difficulty of getting set up with SSL certificates, be sure to check out the Let’s Encrypt project. Let’s Encrypt is a free, automated Certificate Authority that operates with support from a large number of sponsors such as Mozilla, the EFF, Chrome, and Cisco.

Certificate Transparency

Certificate Transparency is a standard for monitoring and auditing certificates (TLS certificates in this case). Its purpose is to help protect against fraudulently issued certificates. Last year when Apple went over App Transport Security, they also briefly covered the ability to require certificate transparency in apps using the NSRequiresCertificateTransparency key, though they said this functionality was off by default.

This year, certificate transparency is still not required, but Lucia Ballard spent several minutes discussing it in the same What’s New in Security session, announcing that Apple is “joining the effort for certificate transparency”. She also took some time to cover OCSP stapling—a method for checking to see if a certificate has been revoked—and presents it as a recommended practice. I think the verbiage used around Certificate Transparency and OCSP stapling is noteworthy. I’ll include the text of two quotes from the session here for your consideration:

We think now is the time for folks to move to it and start adopting [OCSP stapling].

And later:

It would be a great time to start experimenting with certificate transparency, find certificate authorities that are participating, and get integrated into this ecosystem. And please go enable OCSP stapling.

I strongly encourage everybody to go watch, at a minimum, the certificate transparency portion of the What’s New in Security session from WWDC 2016. It’s less than 10 minutes long, starting at 7m55s and ending at 16m00s (though really you should watch the entire session). The speaker gives a great overview of both Certificate Transparency and OCSP stapling. They also recommend certificate-transparency.org as a developer resource on the subject.

Updating your apps

Your first priority should be to get your app ATS compliant before the January 1st deadline. Really you should start now because many developers are going to encounter obstacles in doing so. Don’t procrastinate.

Once you have ATS working, it seems like it will be worth your time to start getting familiar with certificate transparency and OCSP stapling. Not only will this benefit the security of your users, but it may make your life easier down the road should Apple choose to encourage its adoption more strongly.