Securing Network Connections using ServerTrust in your iOS app
When connecting to a web service with your iOS App, Apple has given developers the ability to secure this communication with HTTPS, which is the addition of an SSL/TLS layer on top of HTTP, providing two guarantees inherited from TLS:
- On-the-wire privacy - protection from someone who can see but not modify packets in communication between client and server
- Client-authenticates-server authentication - protection from someone who can both see and modify packets in communication between client and server
iOS devices have many root certificates from trusted certificate authorities, so in most cases it will not be necessary to turn off this certificate exchange and possibly compromise security in form of man-in-the-middle attacks.
To achieve this, there will be both client certificate validation and server certificate validation.
Client certificate validation
In this scenario, the server will be validating the client's certificate. The certificate must be added as a bundle to the iOS app's project, where the
shouldTrustProtectionSpace method will be used to load the certificate in order to establish a trust chain in the server's protection space, anchored on the bundled certificate (the client certificate is provided by the server) .
The trust result will then be stored in a
SecTrustResultType object, populated by the
SecTrustEvaluate method . For more information on the possible results of the trust evaluation, please see the corresponding Apple Documentation -
Server certificate validation
The client validates the server's SSL certificate used during the network connection by comparing to a certificate stored on the client. This is done by comparing the certificate data hashes (e.g. SHA256).
All together now
NSURLConnection is being used to make the network connection and
willSendRequestForAuthenticationChallenge as the delegate method,
shouldTrustProtectionSpace can then be called to validate the client certificate. If successful, the server's certificate is then hashed and compared to the hash value (e.g. EXPECTEDCERTIFICATEBASE64_SHA256)
If the hash comparison is also successful, it is now safe to pass the user's credentials using the
Before you go
It may not be necessary to implement a mutual authentication scheme using this certificate exchange protocol. However, for those apps that transfer sensitive user data, using this two-way certificate exchange is the best security option.
For more information, see: