A path to enabling ATS for my app

I have an app that's been around a long time, and it disables ATS (with NSAllowsArbitraryLoads set). I'd like to enable ATS, but there is some fear that doing so could break connectivity for some of our users. This is due to the

What I'd like to be able to do, is identify how many and which users might be affected if ATS were enabled. As far as I can tell, ATS doesn't have any kind of "warn-only" mode that could be used for this sort of purpose. If it did, I imagine being able to collect information whenever the app makes a successful request that would have failed if ATS were enabled.

(If this exists and I just haven't found its documentation, then I'd be happy to use it; otherwise, I think it would be a nice feature)

So I'd like to try to build this parity mode myself. The docs list the things ATS enforces, which I'll summarize here:

  • TLS 1.2+
  • Perfect Forward Secrecy via ECDHE key exchange
  • AES 128 or AES 256 encryption
  • server presents an X.509 certificate with an intact digital signature, that isn't expired, and has a name that matches the server's DNS name, and is signed, so that its trust chain ends in an anchor certificate trusted by the system
  • server certificate is signed with an RSA key (2048+ bits) or an ECC key (256+ bits)
  • server certificate uses SHA-256 or stronger digest

My understanding is that with ATS disabled, then by default https connections are still subject to the basic certificate trust checks, but not to the extended checks (key bit length and digest strength), nor are the connections subject to the ATS checks (TLS protocol version, PFS requirement, encryption requirement).

At first, I hoped I could wrap or subclass URLSession to test these things, but while URLSession does allow us to set the minimum TLS protocol version, it doesn't seem to allow us to specify cipher suites (so no enforcing/checking the key exchange or encryption algorithms).

So then I decided to explore using Network directly, which does allow granular control over the cipher suites offered during TLS handshake. However, I couldn't find documentation on the exact set of suites offered by an iOS app with ATS enabled. There are cipher suite groups, but I couldn't find any documentation about what they mean. It appears, based on my testing, that adding .ats AND .ats_compatibility groups gives the cipher suites that an app with ATS enabled would offer - is that correct?

That only leaves verifying the server certificate digest strength and key length. I'm also having trouble finding APIs to help with that part - can anyone point me in the right direction?

It looks like I didn't finish my thought in my first paragraph. We fear breaking connectivity for some of our users for two reasons:

  1. We load content (in a web view), the source of which we don't control.
  2. Some of our users' devices are configured so that communication to our servers is intercepted, and we don't control the interception process.
A path to enabling ATS for my app
 
 
Q