Category: Privacy

Categories
iOS Networking Privacy Security

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.

Categories
iOS Mac Privacy Security

Working with Apple’s App Transport Security

Update 6/23/15: Apple now has official documentation for App Transport Security.

With iOS 9 and OS X El Capitan, Apple has introduced App Transport Security. In a nutshell, App Transport Security enforces best practices for secure network connections — notably, TLS 1.2 and forward secrecy. In the future, Apple will also update these best practices to ensure they always reflect the latest security practices that will keep network data secure.

App Transport Security is enabled by default when using NSURLSession, NSURLConnection, or CFURL in iOS 9 or OS X El Capitan. Unfortunately for many developers this may mean that things break as soon as they build for iOS 9 or OS X 10.10. Fortunately Apple offers some configuration options to leverage App Transport Security where possible, while disabling it in places where you cannot support it.

You can opt-out of ATS for certain URLs in your Info.plist by using NSExceptionDomains. Within the NSExceptionDomains dictionary you can explicitly define URLs that you need exceptions for with ATS. The exceptions you can use are: NSIncludesSubdomains
NSExceptionAllowsInsecureHTTPLoads
NSExceptionRequiresForwardSecrecy
NSExceptionMinimumTLSVersion
NSThirdPartyExceptionAllowsInsecureHTTPLoads
NSThirdPartyExceptionMinimumTLSVersion
NSThirdPartyExceptionRequiresForwardSecrecy
Each of these keys allows you to granularly disable ATS or particular ATS options on domains where you are unable to support them.

Sample ATS plist

In the first beta of iOS 9, these keys are incorrect and instead you’ll need to use the following: NSTemporaryExceptionAllowsInsecureHTTPLoads
NSTemporaryExceptionRequiresForwardSecrecy
NSTemporaryExceptionMinimumTLSVersion
NSTemporaryThirdPartyExceptionAllowsInsecureHTTPLoads
NSTemporaryThirdPartyExceptionMinimumTLSVersion
NSTemporaryThirdPartyExceptionRequiresForwardSecrecy

These keys will undoubtedly be fixed in a future seed. If you can, you should use the first set of keys above that Apple is officially supporting, though if you’re using the temporary keys, they should continue to work in future betas. Thanks to Juan Leon for bringing this to my attention—I was told the same in the labs.

Below are examples of different scenarios developers may encounter.

Example A: ATS for all

This is the easiest one. The only thing you need to do is use NSURLSession, NSURLConnection, or CFURL. If you’re targeting iOS 9 or OS X El Capitan or later, ATS’s best practices will apply to all of your NSURLSession, NSURLConnection, and CFURL traffic.

Example B: ATS for all, with some exceptions

If you expect all of your domains to work with ATS, except a few that you know will not work, you can specify exceptions for where ATS should not be use, while leaving all other traffic opted in. For this scenario, you’ll want to use an NSExceptionDomains to specify the domains for which you wish to override ATS’s default settings. To opt-out an entire domain or sub-domain, create a dictionary for the URL you want to opt-out of ATS, then set NSExceptionAllowsInsecureHTTPLoadsto true. You can also specify more specific rules you wish to override with NSExceptionRequiresForwardSecrecy and NSExceptionMinimumTLSVersion if you don’t want to completely disable ATS on those domains.

ATS for All

Example C: ATS disabled, with some exceptions

Conversely, you may only want ATS to work on domains you specifically know can support it. For example, if you develop a Twitter client, there will be countless URLs you may want to load that may not be able to support ATS, though you would want things like login calls, and other requests to Twitter to use ATS. In this case you can disable ATS as your default, then specify URL which you do wish to use ATS.

In this case you should set NSAllowsArbitraryLoads to true, then define the URLs that you want to be secure in your NSExceptionDomains dictionary. Each domain you wish to be secure should have its own dictionary, and the NSExceptionAllowsInsecureHTTPLoads for that dictionary should be set to false.

ATS Disabled with Exceptions

Example D: Downgraded ATS

In some cases you may want ATS on all, or some, or your URLs, but are not ready to fully support all of ATS’s best practices. Perhaps your servers support TLS1.2, but don’t yet support forward secrecy. Rather than completely disabling ATS on the affected domains, you can leave ATS enabled, but disable forward secrecy. In this scenario you would create an NSExceptionDomains dictionary, a dictionary entry for each domain you need to override settings for, then set the NSExceptionRequiresForwardSecrecy value to false. Similarly, if you wish to have forward secrecy enabled, but need the minimum TLS version to be lower, you can define your supported TLS version with the NSExceptionMinimumTLSVersion key.

Downgraded ATS

Example E: NSA-friendly Mode

If you want to opt-out of ATS entirely (which you really shouldn’t do unless you fully understand the implications), you can simply set NSAllowsArbitraryLoads to true in your Info.plist.

NSA-friendly Mode

Third-party keys

You may have noticed a few keys that appear to be duplicates of others keys with the addition of “ThirdParty” in the name. NSThirdPartyExceptionAllowsInsecureHTTPLoads
NSThirdPartyExceptionMinimumTLSVersion
NSThirdPartyExceptionRequiresForwardSecrecy
Functionally these keys will have the same result as the keys that don’t have “ThirdParty” in them. The actual code being invoked behind the scenes will be identical regardless of whether you use the ThirdParty keys or not. You should probably use whichever key best fits your exceptions, but no need to overthink it.

Certificate Transparency

While most security features for ATS are enabled by default, certificate transparency is one you must opt-in to. If you have certificates which support certificate transparency, you can enable certificate transparency checks with the NSRequiresCertificateTransparency key. Again, if your certificates don’t yet support certificate transparency, by default this check will be disabled.

If you need help debugging issues that arise from having App Transport Security enabled, setting CFNETWORK_DIAGNOSTICS to 1 will log all NSURLSession errors including the URL that was called and the ATS error that resulted. Be sure to file radars for any issues you encounter so that ATS can be improved and flexibility expanded.

All of the above information was provided in Apple’s Networking with NSURLSession session at WWDC 2015. Finally, Apple emphasized in the talk to report any issues that you run into and keep any eye out for any changes that may be coming in future betas.

Categories
iOS Mac Privacy Security

Security & Privacy Changes in iOS 8 and OS X Yosemite

I’ve been sifting through this year’s WWDC videos looking for all of the interesting bits around security & privacy. I’m not anywhere close to being done. Fortunately Luis Abreu has done the hard work for all of us and compiled his findings into a very handy post. The post has a lot of great info for developers, QA, and designers around what’s new and what’s changing. Of course you’ll still want to go do your own research before implementing any changes, but Luis’ post serves as a great quick-start guide.

Link: lmjabreu.com
Source: iOS Dev Weekly

Categories
iOS Privacy

The Truth About Apple’s “Limit Ad Tracking” Feature

Discussions have been taking place for a long time about Apple’s deprecation of UDIDs, what options developers have for replacing their use, and what it means for user privacy. Since Apple has now officially announced that developers can no longer use UDIDs as of May 1st, it seemed worth taking a closer look. What I found when looking into Advertising IDs, identifiers for vendors (IDFVs), and the “Limit Ad Tracking” feature that Apple added in iOS 6 was a lot of confusion and misinformation about how all of these things worked. To try and bring some clarity to the issue, I decided to do a detailed write-up on Double Encore’s website. The explanation is geared more toward end users, but I think even more technical folks may gain some insight from it.

Huge thanks to Doug Russell for the sample app he provided that let me explore how Advertising IDs and IDFVs work.