For one of our sleek
iPhone banking apps, we needed to verify details of the SSL/TLS certificate
handling on iOS. Specifically, we were interested in the matter of the certificate revocation
mechanisms (CRL, OSCP) in the NSURCConnection when using the HTTPS protocol.
If you start digging into the problem a bit, you get only a vague
information about the fact the OCSP
is used for the certificate
revocation on iOS.
However, this was not good enough for us. We needed to be absolutely sure
about how the things work under the hood. Therefore, we asked Apple engineers
for an assistence with this issue.
In a blazing fast pace, we received a perfect, qualified response from an
Apple engineer (a complete answer – read it all!):
Currently there is no way to configure the OCSP policy on iOS. This would
make a good enhancement
OCSP checking is done by the trust object (SecTrust).
The checking is enabled by the policy object (SecPolicy)
that you pass in when you create the trust object. The generic X.509 policy (SecPolicyCreateBasicX509)
does not do OCSP checking; the TLS security policy (SecPolicyCreateSSL)
does. It's this policy that's used by high-level TLS frameworks, including CFSocketStream,
Currently all OCSP checking is “best attempt”. That is, when you, or the
system, evaluates a trust object (by calling SecTrustEvaluate)
the trust object will attempt to contact the OCSP server. If it can contact the
OCSP server and the server indicates that the certificate has been revoked, the
trust evaluation will fail. If it can't contact the OCSP server, the trust
evaluation will not fail (unless it fails for some other reason).
This implies that SecTrustEvaluate is a blocking network operation;
it's probably not a good idea to call this on the main thread. At this point
there's no equivalent to Mac OS X's SecTrustEvaluateAsync, although that
would also make a good enhancement request IMO.
To prevent trust evaluation taking too long, it uses a short timeout for
network operations (currently 7 seconds). This timeout applies to each network
operation it makes; it can multiple network operations (for example, there could
be multiple OCSP responders, or it might need to fetch intermediate certificates
referenced by the Authority Information Access extension, as described in
Section 18.104.22.168 of RFC
5280)), so the overall timeout might be much longer.
Finally, there's one critical wrinkle here. Currently the trust object will
only do OCSP checking for Extended
Validation (EV) certificates
Did you like this post? Follow @inmite on Twitter!