Peer review! SecureTransport (native SSL on iOS/OS X) patch
Date: Sun, 24 Jun 2012 16:39:01 -0600
I couldn't let Windows users have all the fun with the next major release of Curl, so yesterday I added preliminary support for SecureTransport.
SecureTransport is the name of the SSL API that comes with the Security framework that is part of iOS and Mac OS X. This is the SSL API that is used by Apple apps such as Safari and iChat. Yes, I'm aware that OS X ships with OpenSSL, but iOS doesn't ship with OpenSSL, so this will make it possible to port Curl to iOS with SSL support. (Also, the build of OpenSSL that ships with OS X is deprecated, and I've had some interesting stability problems with it in the past.)
SecureTransport supports TLS1, SSL2, and SSL3. I've turned SSL2 off by default in this patch, since the other SSL engines supported by Curl do the same thing. SecureTransport does its trust evaluation internally during the handshake using certificates acquired from the system and user keychains, so there's no need for a certificate bundle when using it. It also supports non-blocking I/O.
Although SecureTransport does support customizing the engines, I did not implement it in this patch, because the framework uses numbers to represent engines instead of strings, and Curl apparently wants to work with only strings for engine identifiers.
I've attached the patch, but it isn't quite RFPT yet, due to a couple of things:
1. All of the tests that pass with OpenSSL enabled pass with SecureTransport enabled, except for test 405. How do I debug a specific unit test so I can figure out what's going on here? I'd prefer using GDB, but if that won't work, I'm wondering if there's a way to see the verbose output.
2. Would anyone mind if I added a new selector to the curl_easy_getinfo() function that returns an OS-specific data structure? I ask because, if the trust fails, it's customary on Mac OS X for the app to present a certificate error window to the user showing the problem and asking if the user wants to proceed or cancel the connection . To do that, Curl needs to be able to share the underlying trust data structure (which is called "SecTrustRef") with the rest of the app. I thought about using CURLINFO_CERTINFO, which is the OpenSSL equivalent, but since the return type is totally different, that'll break every app that expected a curl_certinfo list in return.
- application/octet-stream attachment: securetransport.patch