NSURLAuthenticationMethodServerTrust is ssl

Question

I have trouble understanding NSURLAuthenticationMethodServerTrust. In my App I have to use both http and https connections based on the server. My questions is If I get a NSURLAuthenticationMethodServerTrust challenge will it be a safe assumption to take is as https connection. What exactly should I respond to this challenge.

Any help would be appreciated. Thanks

Answer 1

I'm not sure whether receiving NSURLAuthenticationMethodServerTrust always indicates an https connection. I don't see why or how a plain http connection could cause an NSURLAuthenticationMethodServerTrust authentication challenge so I'd assume it's https but I don't know for certain. But the NSURLAuthenticationChallenge has an NSURLProtectionSpace, which in turn has a property receivesCredentialSecurely. The documentation is a bit unspecific, but I'd assume that this property indicates a secure connection to the server which in the http/https case would mean it's https.

Regarding what to respond, there is a helpful thread on the macnetworkprog-mailinglist regarding this topic: Question + Answer

Summary: The NSURLAuthenticationMethodServerTrust is not about you, the client, responding to an authentication challenge of the server but instead giving you, the client, the opportunity to check whether you should even trust the server at all. In that case the protectionSpace of the challenge contains a serverTrust object/struct that contains all the information needed to validate whether this server should be trusted. Generally, you would use the SecTrustEvaluate function to check the serverTrust and act according to the result of that check. You can find more information here: Overriding TLS Chain Validation Correctly

If the check determines that the server should be trusted you create an NSURLCredential with the serverTrust object and pass that to the authentication challenge sender/completion block.

You can find a quite extensive example project by Apple here: http://developer.apple.com/library/ios/#samplecode/AdvancedURLConnections/Introduction/Intro.html It's quite old (iOS 3/4, pre-Arc) and only dealing with the old NSURLConnectionDelegate which had to delegate methods instead of one (like the new one and NSURLSessionDelegate). But the verification shown there and the different scenarios that you could implement still apply and should be easily transferable to NSURLSession.