any ATS policy changes in iOS 10.1?

I have an app and test server combo that worked fine with ATS defaults as of iOS 9 and (until just recently) iOS 10. After upgrading one of our test iPads to 10.1, we're seeing TLS negotiation failures. Obviously there are any number of things that can go awry in a TLS negotiation, but if anyone (*cough* eskimo *cough*) knows of any ATS policy differences between 10.1 and previous iterations, I'm all ears.


-Jared

Accepted Reply

Thanks Quinn. The "resolution" to this issue is itself a bit of a brain-teaser.


Before the iPad in question was updated to 10.1, it had a Profile installed to trust an Issuing CA local to our test environment.

After the iPad was updated to 10.1, this Profile appeared to still be in place, and "worked" insofar as Safari didn't complain when loading https URLs against servers with IssuingCA-issued identities. Of course, Safari isn't a great litmus test since it does its own exemption stuff.

In the spirit of "everyone out of the car, everyone back in the car" we tried removing the Profile and reinstalling it.

After doing so, the connection inside our application that had been failing consistently was able to negotiate without issue.

Replies

FWIW, doing a:

nscurl --ats-diagnostics

against the server in question, from a Mac running 10.11.6, reports:

Default ATS Secure Connection

---

ATS Default Connection

Result : PASS

To be clear, TLS connection failures are not all the fault of ATS; ATS adds extra security checks on top of:

  • the default (RFC 2818) security checks done by NSURLSession

  • the core TLS negotiation done by Secure Transport

Both of these can fail independently of ATS.

You can check whether a TLS connection failure is related to ATS by turning off ATS for your entire process. To do this, remove any

NSAppTransportSecurity
you have and add one that contains just
NSAllowsArbitraryLoads
. If that fixes the problem, you need to look to ATS. OTOH, if the problem persists, you need to look lower.

Oh, and btw, to answer your direct question, I’m not aware of any ATS (or lower) changes that might trigger this change of behaviour in 10.1. The ATS changes that I know about — which are designed to make ATS behave as its documented to behave — are coming in 10.2. See this thread for more info.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks Quinn. The "resolution" to this issue is itself a bit of a brain-teaser.


Before the iPad in question was updated to 10.1, it had a Profile installed to trust an Issuing CA local to our test environment.

After the iPad was updated to 10.1, this Profile appeared to still be in place, and "worked" insofar as Safari didn't complain when loading https URLs against servers with IssuingCA-issued identities. Of course, Safari isn't a great litmus test since it does its own exemption stuff.

In the spirit of "everyone out of the car, everyone back in the car" we tried removing the Profile and reinstalling it.

After doing so, the connection inside our application that had been failing consistently was able to negotiate without issue.

Whoa, that’s weird. Well done for getting to the bottom of it.

I’d appreciate you file a bug about this. Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"