Did ATS Change Since the GM?

I did not think I would be writing about App Transport Security two weeks running. Last week I wrote up my notes on how I was debugging ATS. I was testing the Twitter search API which uses TLS v1.2 with a strong cipher suite for forward secrecy. It was getting rejected by ATS due (I think) to a weakly signed certificate. The solution was to add the NSThirdPartyExceptionAllowsInsecureHTTPLoads exception to the App Info.plist.

I wrote that post based on my experience testing ATS with the iOS 9 GM release on actual devices. What I did not expect is that the result would change after I updated to the over-the-air public release of iOS 9.

Are You Sure NSCurl?

This week I upgraded an older machine to the OS X 10.11 El Capitan GM Candidate. This means I can try the new NSCurl utility which has an ATS Diagnostic mode. Naturally I decided to see if it gave results that matched my expectations. The basic usage of NSCurl is as follows:

$ nscurl --ats-diagnostics -v https://api.twitter.com

What makes nscurl potentially helpful is that it tests connections with the various ATS checks disabled and shows you if the connection works or not. For example, allowing TLS v1.0 and v1.1 or disabling the check for forward secrecy. With the -v flag it will also show the settings you need to add to Info.plist.

What surprised me was that the default ATS policy passed when based on my tests with the GM release it should have failed:

Default ATS Secure Connection
ATS Default Connection
ATS Dictionary:
Result : PASS

This is not what I was expecting but sure enough when I went back and tested on the upgraded device the exception was no longer needed.

So did Apple change the ATS policy between the public and GM releases? It sure seems like it. Luckily I have the CFNetwork debug logs from the device for both the failing GM test and the successful public release test. I have filed a bug (22763438) with Apple to see if they can explain what is happening. If I learn something that changes how we need to use ATS I will update here.

What Does It All Mean?

At this point it is not clear to me if Apple has relaxed the security checks to allow SHA1 signed certificates or if this is a bug - or I am misunderstanding what I am seeing which is always possible ;-)

A clue to what might be happening is in this Apple Developer forum thread. It seems there is/was a bug where setting NSExceptionRequiresForwardSecrecy had a side effect of relaxing the SHA-256 signature requirement. Maybe Apple has relaxed the requirement so as not to break any Apps that now depend on the undocumented side effect of disabling forward secrecy.

My thought until I learn more is to keep the exception in place even though it seems like it is no longer needed. The worst that can happen this way is that users are no less secure than they were with iOS 8.