How to compare SSL certificates using AFNetworking
In my iPhone app I’m using an
https connection with a self-signed
SSL certificate to download sensible data (username and password) from a server.
This app is for private use only, it is not meant for production.
AFNetworking to manage the
https connection but, since my certificate isn’t signed from a CA, in order to make it work I had to add the following to the header of the
#define _AFNETWORKING_ALLOW_INVALID_SSL_CERTIFICATES_ 1
But with this my app will allow any certificate.
Is there a way to allow only the certificate from my server maybe bundling it in the app and comparing it with the certificate provided by the server in the https connection?
And if it were possible, would there be any significant advantage in terms of security?
I’m very new to security and I’m kind of confused.
2 Solutions Collect From Internet About “How to compare SSL certificates using AFNetworking”
The term you’re looking for is SSL Pinning, where the app verifies that a known certificate or public key matches one presented by a remote server.
AFNetworking supports both pinning with certificates or public keys. You’ll need to add the certificate(s) or public key(s) to your app’s Bundle, and enable the feature by setting either the
defaultSSLPinningMode property on AFHttpClient or the
SSLPinningMode property on
You can pin using
AFSSLPinningModeCertificate means that the server’s certificate must exactly match one of those in the bundle.
AFSSLPinningModePublicKey is more liberal and means that the server’s certificate must match for any public key in the bundle, or any public key attached to certificates in the bundle.
There’s an example of setting the pinning mode in the AppDotNet example.
To expand a bit on David’s answer with respect to
AFSSLPinningModeCertificate. Ideally, you would pin the public key and not the certificate. That’s because some sites and services, like Google, rotate their certificates every 30 days or so. But they re-certify the same public key.
The certificates are rotated frequently to keep the size of the CRL small for mobile clients. But they re-certify the same public key (rather than creating a new one) to allow for key continuity testing.
Public key pinning is why tools like Certificate Patrol miss the mark. The certificate is expected to change; the public key is not.
Public key pinning is a lot like SSH’s
StrictHostKeyChecking, if you are familiar with it.
OWASP has a write-up on it too at Certificate and Public Key Pinning.
- How to write a flip method in Swift?
- Getting the count of an optional array as a string, or nil
- Unable to set custom font for the UILabel in XCode
- PSCollectionView's delegate not fire
- gradient cut from top to bottom
- iOS Simulator: Invalid device state
- CGAffineTransformScale not working with zero scale
- Objective-C and Swift URL encoding
- window.close() doesn't work on iOS
- Sharing with iOS 6.0 native Facebook integration: “Posted via my app name”?
- Alamofire can't access keys of json response
- How do I retrieve keystrokes from a custom keyboard on an iOS app?
- CMake and XCode: “cannot find interface declaration for 'NSObject'”
- Making a SKScene's background transparent not working… is this a bug?
- Minimum Font Size deprecated on ios version 6.0