Post not yet marked as solved
This seems to be the same problem addressed here, am I right?
Post not yet marked as solved
I did just that: Calling SecTrustEvaluateAsyncWithError (on a background queue) myself before calling SecTrustCopyCertificateChain (on the main queue). The latter, however, lead to Xcode printing "This method should not be called on the main thread as it may lead to UI unresponsiveness." which apparently resulted from SecTrustCopyCertificateChain calling SecTrustEvaluateIfNecessary even though I had already done that. So I ended up calling SecTrustCopyCertificateChain on the background queue as well.
Post not yet marked as solved
Sorry, but I have another question: To do my own checks I need to call e.g. SecTrustCopyCertificateChain(_:) on the trust object. Is that API guaranteed to return the correct certificate chain if the trust object has not been evaluated?
Post not yet marked as solved
Thank you. It was not obvious (to me) that continuing with completionHandler(.useCredential, URLCredential(trust: serverTrust)) does not benefit from the OS performing trust evaluation.
Post not yet marked as solved
Sure: I am required to implement HPKP (aka. Public Key Pinning Extension for HTTP) as defined in RFC 7469 which is not supported out of the box (cf. FB5986841). Additionally I have to secure the first-ever connection as well by supporting preloaded pins, but I cannot use Identity Pinning (cf. thread and FB12333846). So I have to build everything from scratch.
Post not yet marked as solved
I see. However, doing this:
Leave ATS enabled.
Intercept the server trust authentication challenge (NSURLAuthenticationMethodServerTrust).
Apply your extra checks.
Complete the challenge with .performDefaultHandling.
causes the trust evaluation to be performed after the extra checks, correct? What if I wanted to have the system check be done first - then I would to resort to calling SecTrustEvaluate myself?
Post not yet marked as solved
Thanks. Does that mean the example code
if checkValidity(of: serverTrust) {
let credential = URLCredential(trust: serverTrust)
completionHandler(.useCredential, credential)
}
does not perform trust evaluation?
Post not yet marked as solved
FWIW, the resolution of the feedback I filed was basically "works as designed".
Post not yet marked as solved
This does not actually symbolicate the crash log for me. I filed FB13543963 about this.
Post not yet marked as solved
FWIW:
If so, the next step is to confirm that the data and its signature made it to your server intact. On both the iOS and server side, generate an independent hash of the data and the signature and check that they match.
Turns out this was the issue, the cause being the same as the one discussed in this thread. But thanks anyway.
Post not yet marked as solved
@eskimo I am not really getting anywhere with this so far other than that I can confirm the problem still persists in yesterday's beta 7. Would it be helpful if I opened a DTS incident for this?
Post not yet marked as solved
Thank you for the clarification. I had hoped, though, that there was a way to proceed (the certificate the SPKI fingerprint from the Info.plist belongs to may since have expired, but the app may have knowledge of the current certificate's SPKI hash).
Post not yet marked as solved
For the record:
I suspect that you may be able to do this using one of the data representations, but I’ve not investigated that in depth.
I tried converting a Keychain key to a CryptoKit key by utilising SecKeyCopyExternalRepresentation(_:_:), but as the documentation suggests that does not work:
The operation couldn’t be completed. (OSStatus error -4 - export not implemented for key <SecKeyRef:('com.apple.setoken') (which should be errSecUnimplemented).
Post not yet marked as solved
Thanks Quinn. Would it be possible then for someone other than Apple to create a profile (with a payload unrelated to logging) that auto-expires after installation?
Post not yet marked as solved
Thanks Quinn, I did as you suggested (FB12036482).
