document limitations of TSKAdditionalTrustAnchors on iOS 11

[bjlaub]

As far as I can tell, App Transport Security (when fully enabled) no longer allows evaluating TLS trust using custom anchors in iOS 11. This means that setting kTSKAdditionalTrustAnchors will have no effect if ATS is enabled. This behavior of ATS seems to be distinctly different from iOS 10, which does allow evaluation using custom anchors even if ATS is enabled. On iOS 10, setting kTSKAdditionalTrustAnchors works as expected.

This limitation on iOS 11 should probably be documented, so as not to catch folks (like me) off-guard.

See also: https://stackoverflow.com/questions/46316604/ios-11-ats-app-transport-security-no-longer-accepts-custom-anchor-certs

and Apple's notes on ATS requirements which state

The X.509 digital server certificate must meet at least one of the following trust requirements:

• Issued by a certificate authority (CA) whose root certificate is incorporated into the operating system
• Issued by a trusted root CA and installed by the user or a system administrator

(from: https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW57)

[nabla-c0d3]

Hello and thanks for letting us know - that's a very interesting change from Apple. We will do more testing on our side and update the documentation as needed.

[vicdelfant]

We're having some difficulties getting SSL pinning with a custom root certificate to work, probably also because of the ATS limitation. @bjlaub did setting the NSExceptionDomains work for you?

[nabla-c0d3]

I will do my own testing this week as well.

[bjlaub]

@vicdelfant you should still be able to pin a custom CA cert in the usual way, but iOS needs to trust the certificate. The issue here is that, it seems, with iOS 11 you can no longer programmatically set anchor certs for trust evaluation, without also disabling ATS.

You can add certs for iOS to use by opening them in Safari and clicking through the prompts to install the certificate - since iOS 10.3 you also need to explicitly tell iOS to trust them after they are installed (see https://www.thesslstore.com/blog/trust-manually-installed-root-certificates-in-ios/). As far as I know the only ways to get iOS to trust custom CA certs is to do this process manually, or deploy them via an MDM.

[nabla-c0d3]

@bjlaub Do you know which specific ATS exemption is needed for custom anchors to work again?

[bjlaub]

i think you can disable ATS for a specific domain by setting NSExceptionAllowsInsecureHTTPLoads to YES for that domain in the ATS config block.

Per https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW44:

Set this key’s value to YES, if needed, to:
- Enable connection to an insecure HTTP server
- Enable connection to an untrusted HTTPS server
- Enable connection to an HTTPS server for which you want to perform your own server trust evaluation

This has the downside of apparently also allowing insecure HTTP loads for that domain. FWIW, in my testing i think this worked for NSURLSession, but it seemed to behave differently for WKWebView and it wasn't clear exactly why - so i ended up abandoning this approach :(

[nabla-c0d3]

Very interesting. Yeah that exemption is pretty dangerous, so Apple clearly wants to get rid of customized SSL validation. I will try it out as well.
Thanks!

[vicdelfant]

Thanks!

We have tested using NSExceptionAllowsInsecureHTTPLoads for our specific hostname but the issue still remains... validation-result comes back as 2, but with the custom root CA installed onto the device everything works. Distributing the root certificate to all users is a no-go for us unfortunately, so I really hope there's a way to work around this.

We have reached out to Apple Developer Technical Support with a link to this issue, hopefully they can shed some light on this as well. I'll report back if they do.

[nabla-c0d3]

I finally had some time to look into this. Unfortunately I don't think there's a workaround; the root certificate must be installed on the device on iOS 11, as disabling ATS just for this would be too dangerous.

It's also clear that it is Apple's intent to limit how much developers can customize their app's SSL validation (to prevent mistakes, which is good); even if there was a workaround, it probably would stop working on the next version of iOS.

Hence, my plan is to also remove the TSKAdditionalTrustAnchors option in the next release, which is now useless because of the changed described in this thread. @adamkaplan any objections?

Thanks!

[nabla-c0d3]

There's more information about this in the main article about ATS:

Your ability to loosen HTTPS server trust evaluation requirements depends on whether or not App Transport Security (ATS) is enabled for a domain, as follows:

• If ATS is enabled for a domain, you cannot loosen the system’s HTTPS server trust evaluation requirements.
• If ATS is not enabled for a domain, the system nonetheless performs HTTPS server trust evaluation, but you can loosen this requirement as described in HTTPS Server Trust Evaluation.

Whether or not ATS is enabled for a domain, you can tighten trust evaluation requirements, such as by implementing certificate pinning

[adamkaplan]

@nabla-c0d3 No objections from me.

The feature is now partially obsolete with new Security Framework on-device proxying (Charles Proxy iOS app). “break glass” self-signed backup keys were nice to have, but not a deal breaker. Thanks for checking.

[vicdelfant]

Seems I completely forgot to let you all know what Apple Developer Technical Support replied with, apologies. Their recommendation was simply to not use our own root CA but use a trusted CA instead (which of course removes the need to disable ATS). Also, they could not confirm nor deny that the ability to add a custom root CA and perform our own chain trust verification by disabling ATS might disappear in the future.

Pinning the public key of the leaf certificate, along with a proper backup pin for an inactive private key, turned out to be sufficient for our use case.

[nabla-c0d3]

Released with v1.6.0.