[SSL Pinning] NSPinnedDomains will be honored by which APIs?

I was able to successfully verify SSL Pinning for URLSession but not for WKWebView. Is this expected?

I have done some testing with URLSession and with WKWebView and I have never been able to correctly setup NSPinnedDomains using WKWebView. There are two active bugs that I am aware of investigating this: (r. 78515370) and (r. 76593876).

I have also seen some inconsistencies with URLSession, for example:

I tried testing the URLSession side of this to get a clear success and failure case but was not able to. Here is what I found for apple.com.

Taking a look at apple.com, I downloaded the CA root as a PEM here:

https://www.digicert.com/kb/digicert-root-certificates.htm

And create a public hash like so:

$ cat DigiCertHighAssuranceEVRootCA.crt.pem | openssl x509 -inform pem -noout -outform pem -pubkey | openssl pkey -pubin -inform pem -outform der | openssl dgst -sha256 -binary | openssl enc -base64

WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=

Then applied it to:

<key>NSAppTransportSecurity</key>
<dict>
	<key>NSPinnedDomains</key>
	<dict>
		<key>apple.com</key>
		<dict>
			<key>NSIncludesSubdomains</key>
			<true/>
			<key>NSPinnedCAIdentities</key>
			<array>
				<dict>
					<key>SPKI-SHA256-BASE64</key>
					<string>WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=</string>
				</dict>
			</array>
		</dict>
	</dict>
</dict>

And NSPinnedCAIdentities should pickup subdomains and should work for www.apple.com, and it does. The issue is that it does not fail when the hash is altered. This test is done with URLSession:

var urlRequest = URLRequest(url: URL(string:"https://www.apple.com")!)
urlRequest.httpMethod = "GET"

let task = URLSession.shared.dataTask(with: urlRequest) { data, response, error in ... }

The same behavior is seen also when using NSPinnedLeafIdentities instead of NSPinnedCAIdentities.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

Hi Matt,

thanks so much for your input! So when you talk about bugs are investigated for URLSession and WKWebView I can assume that those APIs are expected to honor NSPinnedDomains and Apple eventually will provide fixes, right?

What about ASWebAuthenticationSession or SFSafariViewController? Should NSPinnedDomains be honored here theoretically? At least in my testing, I was not able to make it work for SFSafariViewController so I even didn't bother to try for ASWebAuthenticationSession

thanks so much for your input! So when you talk about bugs are investigated for URLSession and WKWebView I can assume that those APIs are expected to honor NSPinnedDomains?

URLSession, yes. WKWebView, I do not know. Last I knew this point was being investigated by that team.

Regarding:

What about ASWebAuthenticationSession or SFSafariViewController? Should NSPinnedDomains be honored here theoretically? At least in my testing, I was not able to make it work for SFSafariViewController so I even didn't bother to try for ASWebAuthenticationSession

I do not have an answer here either. The best recommendation I can provide is if WKWebView is determined to work then I would try NSPinnedDomains with ASWebAuthenticationSession and SFSafariViewController also. If this is not determined to work then I would file Enhancement Requests for these APIs to work with NSPinnedDomains.

Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com

It seems that WKWebView honors NSPinnedDomains from iOS 16 onwards, though it is necessary to delete an app between tests, as caches could provide false-positive results.