I know that ATS needs to be configured statically at build time and is not meant to be (re-)configured at runtime (to quote Quinn: "[...] if ATS is enabled for a domain, developer code should not be able to decrease security for that domain.", cf. https://forums.developer.apple.com/message/159271#159271), but what if I want to increase security? From the documentation: "You can also increase a named domain’s protections by requiring Certificate Transparency" (cf. https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/CocoaKeys.html#//apple_ref/doc/uid/TP40009251-SW35).
We have an app that supports connecting to more or less arbitrary hosts and would like to be able to utilize CT for any host that supports it, which obviously we don't know at build time.
To the best of my knowledge there is no way to achieve that; am I correct?
I wanted to post a summary of what I learnt about this:
is an override for the platform default. If you set it to true, the connection will require certificate transparency (CT) on all versions of the OS which supportNSRequiresCertificateTransparency
. If you set it to false, or leave it out entirely, the platform default will apply.NSRequiresCertificateTransparencyApple’s CT policy is covered by the Apple's Certificate Transparency policy article published by Apple Support.
This document is somewhat vague about when that policy applies. I have confirmed that it is enforced by iOS 12.1.1 (and the related watchOS and tvOS releases) and macOS 10.14.2.
This policy applies to TLS connections made using Apple’s TLS implementation, regardless of the source of the connection. That is, it applies to built-in apps (like Safari), other system processes, and third-party apps equally.
This policy may or may not apply to apps that use their own TLS stacks:
If the app uses its own TLS stack but uses
to do the trust evaluation, the policy applies as above [1].SecTrustIf the app does its own trust evaluation, it’s up to the app to implement CT.
This policy does not apply to certificates issued via custom CAs, where the root certificate is install via MDM, a configuration profile, and so on.
Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"[1] The one caveat here relates to how the TLS implementation passes signed certificate timestamps (SCTs) to the trust object. Remember that there’s three ways to get SCTs:
Embedded in the certificate. This Just Works™
OCSP. The TLS implementation must get the OCSP response and apply it to the trust object via
.SecTrustSetOCSPResponseTLS
extension. Currently there is no way to pass the contents of that extension to a trust object, although we expect to provide such a mechanism in the future (r. 45545270).signed_certificate_timestamp