How to Compare SSL Certificates Using AFNetworking

In my iPhone application, I use an https connection with a self-signed SSL certificate to download reasonable data (username and password) from the server.

This application is intended for personal use only, it is not intended for production.

I use AFNetworking to control the https connection, but since my certificate is not signed from CA to make it work, I had to add the following to the header of the AFURLConnectionOperation class:

 #define _AFNETWORKING_ALLOW_INVALID_SSL_CERTIFICATES_ 1 

But with this my application any certificate will be allowed.

Is there a way to allow only the certificate from my server, connect it in the application and compare it with the certificate provided by the server in the https connection? And if it were possible, was there any significant security advantage?

I am very new to security and I'm a little confused.

+8
security ios ssl afnetworking
source share
2 answers

The term you are looking for is SSL Pinning, where the application verifies that a known certificate or public key matches the one provided by the remote server.

AFNetworking supports both commit certificates and public keys. You will need to add a certificate or public key to your application package and enable the function by setting either the defaultSSLPinningMode in the AFHttpClient or SSLPinningMode property to AFURLConnectionOperation .

You can use AFSSLPinningModePublicKey or AFSSLPinningModeCertificate . AFSSLPinningModeCertificate means that the server certificate must exactly match one of them in the packet.

AFSSLPinningModePublicKey is more liberal and means that the server certificate must match any public key in the kit or any public key attached to the certificates in the kit.

In the AppDotNet example, there is an example of setting pinning mode .

+21
source share

To slightly increase David's answer regarding AFSSLPinningModePublicKey compared to AFSSLPinningModeCertificate . Ideally, you should specify a public key, not a certificate. This is because some sites and services, such as Google, rotate their certificates every 30 days or so. But they re-certify the same public key.

Certificates often rotate to reduce CRL size for mobile clients. But they re-certify the same public key (rather than create a new one) to provide verification of key integrity.

Public key binding is why tools like Certificate Patrol do not match the value. The certificate is expected to change; the public key is not.

Public key binding is very similar to SSH StrictHostKeyChecking if you are familiar with it.

OWASP also has a link to the Certificate and public key link.

+7
source share

All Articles