How to use NSURLConnection to connect with SSL for an untrusted cert

Connecting to servers with untrusted SSL certificates using NSURLConnection can be tricky, but it’s often necessary during development or when dealing with self-signed certificates in internal networks. While bypassing SSL verification entirely is generally discouraged due to security risks, understanding how to do so in specific, controlled situations can be crucial for iOS developers. This article provides a comprehensive guide to managing these connections safely and effectively, offering practical solutions and explaining the potential pitfalls.

Understanding the Risks of Untrusted Certificates

Before diving into the how-to, it’s vital to understand why untrusted certificates pose a security risk. Untrusted certificates haven’t been verified by a recognized Certificate Authority (CA). This means there’s no guarantee the server you’re connecting to is actually who it claims to be. An attacker could intercept your connection, present a fake certificate, and potentially steal sensitive data. Therefore, bypassing SSL verification should only be done when you absolutely trust the server and understand the implications.

For instance, imagine connecting to a development server with a self-signed certificate. In this scenario, you likely control the server and know the certificate is legitimate, even though it’s not signed by a CA. Bypassing verification in this controlled environment is acceptable. However, doing so in a production environment with a public-facing server using an untrusted certificate is highly discouraged.

Implementing NSURLConnection with Untrusted Certificates

NSURLConnection, while deprecated, remains relevant for projects maintaining legacy code. To connect with an untrusted certificate, you’ll need to interact with the NSURLAuthenticationChallenge. This challenge is issued when the connection encounters an untrusted certificate, allowing you to decide whether to proceed. The key is to implement the connection:willSendRequestForAuthenticationChallenge: delegate method.

Within this method, you can evaluate the server’s certificate and decide whether to trust it. If you decide to proceed, you can use [challenge.sender useCredential:forAuthenticationChallenge:challenge]; with a suitably configured NSURLCredential. This effectively tells NSURLConnection to ignore the trust issue and continue with the connection.

Here’s a simplified example: objectivec - (void)connection:(NSURLConnection )connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge )challenge { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) { SecTrustRef serverTrust = challenge.protectionSpace.serverTrust; // Evaluate serverTrust here - (see next section for more details) if (/ serverTrust is considered acceptable /) { NSURLCredential credential = [NSURLCredential credentialForTrust:serverTrust]; [challenge.sender useCredential:credential forAuthenticationChallenge:challenge]; } else { [challenge.sender cancelAuthenticationChallenge:challenge]; } } else { [challenge.sender performDefaultHandlingForAuthenticationChallenge:challenge]; } }

Evaluating Server Trust

Blindly accepting any untrusted certificate is a serious security flaw. You need a mechanism to evaluate the serverTrust. One common approach is certificate pinning, where you compare the server’s certificate against a locally stored copy of the expected certificate. This helps ensure you’re connecting to the correct server, even if its certificate isn’t signed by a CA.

Another method is to perform basic checks on the certificate, such as verifying the hostname matches the certificate’s common name. However, this offers less security than certificate pinning. The best approach depends on your specific security needs and the level of risk you’re willing to accept. Resources like OWASP Mobile Top 10 provide valuable guidance on mobile security best practices.

Modern Alternatives: NSURLSession

While NSURLConnection still functions, Apple recommends using NSURLSession for new development. It offers a more modern and flexible API. The principles for handling untrusted certificates are similar, involving evaluating the server trust within the URLSession:didReceiveChallenge:completionHandler: delegate method. NSURLSession provides more control over the network request and offers improved performance.

Using NSURLSession is considered the best practice for current iOS development and offers a more streamlined approach to network operations. For comprehensive documentation and examples, refer to Apple’s official NSURLSession documentation.

• Always prioritize security and avoid bypassing SSL verification unless absolutely necessary.
• When dealing with untrusted certificates, ensure you understand the risks and implement proper validation mechanisms like certificate pinning.

Infographic Placeholder: Visual representation of the SSL handshake process with and without certificate pinning.

1. Identify the NSURLAuthenticationChallenge.
2. Evaluate the serverTrust.
3. Implement appropriate security measures (e.g., certificate pinning).
4. Proceed with the connection or cancel the challenge based on your evaluation.

FAQ

Q: Is it safe to bypass SSL verification?

A: Generally, no. Bypassing SSL verification opens your app to security risks. Only do so in controlled environments (e.g., development servers) and with proper precautions like certificate pinning.

Successfully navigating SSL connections with untrusted certificates requires careful consideration of the security implications. While NSURLConnection provides the necessary tools to manage these connections, always prioritize secure coding practices. By understanding the risks and implementing appropriate validation techniques, you can balance functionality with security in your iOS applications. Explore resources like SSL Labs to learn more about SSL testing and best practices. Consider migrating to NSURLSession for improved performance and a more modern API. If you’re working with sensitive data, consulting a security expert is always recommended.

• Certificate Pinning
• Self-Signed Certificates
• SecTrustRef
• NSURLCredential
• SSL Handshake
• Public Key Infrastructure (PKI)
• Man-in-the-Middle (MitM) Attacks

Question & Answer :
I have the following simple code to connect to a SSL webpage

NSMutableURLRequest *urlRequest=[NSMutableURLRequest requestWithURL:url]; [ NSURLConnection sendSynchronousRequest: urlRequest returningResponse: nil error: &error ]; 

Except it gives an error if the cert is a self signed one Error Domain=NSURLErrorDomain Code=-1202 UserInfo=0xd29930 "untrusted server certificate". Is there a way to set it to accept connections anyway (just like in a browser you can press accept) or a way to bypass it?

There is a supported API for accomplishing this! Add something like this to your NSURLConnection delegate:

- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace { return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]; } - (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) if ([trustedHosts containsObject:challenge.protectionSpace.host]) [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge]; [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge]; } 

Note that connection:didReceiveAuthenticationChallenge: can send its message to challenge.sender (much) later, after presenting a dialog box to the user if necessary, etc.