Unintended security hazards of ATS cert requirements

Our experimentation shows that for some reason, setting NSExceptionRequiresForwardSecrecy will also relax the requirement for SHA1 over the certificate chain.

This is, alas, a bug. See this thread for details.

This will cause careless developers to try and disable cert verification altogether, to make their apps work in the interim.

I think you’re under the impression that disabling ATS disables all HTTPS server trust evaluation. That’s not true. Even if you set

NSAllowsArbitraryLoads

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

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

Well, facebook recommendations for iOS 9 capitalize on that bug, if you look at sample ATS settings from [elided] .

We didn't even consider setting NSAllowsArbitraryLoads to no, Our working assumption is/was that such a setting will need to be justified to apple as part of app submission and would be grounds for rejecting our app if a genuine use case/explanation was not presented.

However, if NSExceptionRequiresForwardSecrecy won't relax SHA1 and we have to work with SHA1 endpoints (e.g. facebook, but most endpoints today simply don't qualify), we'll have to disable ATS entirely and this is highly undesirable. As of writing there is no comitted date from facebook, twitter, apple itself (many endpoints still with SHA1) or anyone else to replacing the certs.

as for NSExceptionAllowsInsecureHTTPLoads, the way i'm reading into documentation is that with ATS and that exception set, your security level/behaviour would be worse than baseline iOS 8, given the instructive nature of that setting. Either way it's not suitable for general use, only for the particular self-signed use case.

I can provide a listing of our own testing of endpoints in private and their SSL compliance level. it's not a pretty sight...

[Administrivia: I had to edit your post to remove the URL so that I could reply promptly.]

What’s your high-level goal here? You started this thread with a very theoretical treatment of the issue but this most recent post seems to be very specific (worrying about App Review rejects of your app and so on). If you can post a summary of what your app does, should be able to provide more concrete advice.

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

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

Hi,

the high-level goal is to see whether apple can assist with guiding at least the more popular endpoint providers for app developers in being compliant, because they aren't...

The onus of trying to get everyone to fix their endpoints so our app would become usable as is without all the exceptions seems very big for us. I've sent our own specific table in private, there are updates. But note we're not doing anything really special, just an app living in a world of interconnected services.

the workarounds (setting exceptions) means that we won't really be testing with ATS, so then we'll have two choices:

1. Activate ATS with little checking when the time comes.

2. Avoid activating ATS, which we don't expect will be easily granted in production (or else, what is the point?)

I want to promote this as a general-interest topic to the benefit of all app developers, not as restitution to the particular endpoints we're using. But we have spotted a few major non-compliant ones.

Just mapping all the endpoints and checking their compliance is not simple (can't use a development MITM proxy, need to exercise all code paths due to external SDKs, need to disable ATS and check synthetically due to breakage, etc)