Certificate Transparency stopped working with iOS 16+

Hi guys!

In my apps I used to enforce certificate trusting using Certificate Transparency (CT) throught NSRequiresCertificateTransparency plist attribute for NSAppTransportSecurity.

Since iOS 16 the feature seems broken (I can intercept and read SSL network traffic of my apps). Reading the documentation the property is reported as "obsolete", saying the system enforces by default such type of check.

Am I missing something?

Thank you in advance

Post not yet marked as solved Up vote post of mpataio86 Down vote post of mpataio86
1.7k views

Replies

NSRequiresCertificateTransparency was never intended as a mechanism to defeat debugging proxies [1]. The weapon of choice for that is the NSPinnedDomains property.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Although you’re not the first person to use it for that.

Hi Quinn,

thank you so much!

Out of curiosity: how does CT now work with iOS 16?

CT has been required by the system for a while now, which is what made NSRequiresCertificateTransparency redundant. The Networking Resources has links to various Apple Support articles about this.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I still don't get the difference between the scenarios I have. The same app, with NSRequiresCertificateTransparency set to YES for a specific domain, running on:

  • iOS < 16: makes any SSL handshake attempt fail if I try to intercept network traffic using a certificate that is not trusted by CT.
  • iOS >= 16: let me intercept network traffic using a certificate that is not trusted by CT. The same happens if I remove the NSRequiresCertificateTransparency key.

If the system already enforces CT making NSRequiresCertificateTransparency redundant, on iOS 16+ shouldn't I get a handshake error every time I try to do SSL proxying with a certificate not trusted by CT?

Thank you!

Add a Comment

We also observed the same behavior @mpataio86 described. CT seems to not be required by the system as @eskimo stated. I'd also like to understand why. We observed that kSecTrustCertificateTransparency == kCFBooleanTrue only when connecting directly without a proxy. I was wondering why this isn't enforced by the default SSL handshake implementation of URLConnection.