Testing SSL Certificates

[Gordon Heydon]

Hi,

I am currently work on an app where we need to communicate with the web service. On this service we have placed a SSL certificate and I want to know the best methods/practices that we should use to test that the certificate is valid, and how we should test this to make sure the app has implemented the SSL handling correctly, so that if the certificate is invalid for any reason it will be rejected.

I know that in the APP we should be rejecting the certificate if it has expired, if the common name is wrong, etc, I remember that because we are an APP only communicating with a single service that we can check other things to make sure there is no man in the middle attach either, but I can't remember that that is, any help would be great.

Also does anyone know of any information to test all this to make sure that it is working as secure as it is needed.

Thanks in advance.
Gordon.

[snare]

Hi Gordon,

The APIs allow you to automatically check the validity of a certificate for the server that provided it, but as you've suggested it is definitely a good idea to also verify other aspects of the certificate if you know your application will only ever be communicating with one particular back end server (or a load balancer terminating the SSL or whatever).

The process of verifying other aspects of a specific certificate is known as "certificate pinning" - this terminology might help you find more information. Typically certificate pinning is done on a per-server certificate or per-CA certtificate basis, or on a more ad-hoc basis. The first two methods involve keeping a copy of a certificate within the application - either the server certificate itself, or the CA certificate - and comparing the certificate provided to the stored one. You can also implement a more ad-hoc approach just by checking various expected values in the certificate fields (other subject details, issuer, issuer details), but this is not quite as reliable. The only benefit of this approach is that you don't need to update a certificate within the app itself when your server SSL certificate expires, but it's much easier for a MITM attack to be performed as the attacker can just replicate all of the fields in the certificate in their own cert. If you do keep a copy of some certificate within the app bundle you will have to be vigilant about getting updates out before the certificate expires, or the app will stop working.

Certificate pinning can be defeated with a willing user and device, but it makes it more difficult. The process for penetration testing against an iOS app that uses a web service without certificate pinning is basically to install a self-signed CA cert via a mobileconfig profile thing (e.g. the one for PortSwigger, makers of the BurpSuite web app pentesting tool), and then running your proxy (Burp) in the middle with a certificate signed by that CA cert. Certificate pinning obviously means that the self-signed cert will not be accepted as valid. The way I've worked around this before (and I believe the way that other people do it, based on the Black Hat slides above) is to use a jailbroken device and a debugger, and patch the executable in memory to remove the certificate pinning check. So not really an attack that you're likely to see against a real user, just a user who is interested in exploring the communications between your app and the back end.

I'm not an expert on the APIs, but here's a couple of resources that might answer your questions a bit further:

https://www.isecpartners.com/news-events/news/2013/february/ssl-pinning-on-ios.aspx

http://media.blackhat.com/bh-us-12/Turbo/Diquet/BH_US_12_Diqut_Osborne_Mobile_Certificate_Pinning_Slides.pdf

Hope this is helpful.

Loukas

--
You received this message because you are subscribed to the Google Groups "Australian Cocoaheads" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cocoaheadsau...@googlegroups.com.
To post to this group, send email to cocoah...@googlegroups.com.
Visit this group at http://groups.google.com/group/cocoaheadsau?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[Gordon Heydon]

Hi,

Thanks for this, I think this is exactly what I need.

Gordon.

[Sadat Rahman]

Hi Gordon,

If you are using the AFNetworking library for communicating with your
web services, then you get the functionality to check for invalid
certificates out of the box, unless you #define
_AFNETWORKING_ALLOW_INVALID_SSL_CERTIFICATES_. Furthermore,
AFNetworking also has built in support for "certificate pinning" (see
Loukas' email). You can enable this by #define
_AFNETWORKING_PIN_SSL_CERTIFICATES_ 1.

Hope this helps as well.

Regards,
Sadat

[Jasper Blues]

Hi Sadat, 

Can you tell us a bit more about the pinning feature? What does that mean? 

I've asked Bruno de Carvalho - author of my current favourite: https://github.com/brunodecarvalho/BBHTTP . . . if his library can also do this. He said that accepting invalid certificates is simple enough, but wanted to know more about the pinning feature. 

Kind Regards, 

Jasper Blues

Landline: +63.2.826.2489

Skype: jasperblues

LinkedIn Twitter

[Nathan de Vries]

On 15 May 2013 19:24, Jasper Blues <jasper....@gmail.com> wrote:

Can you tell us a bit more about the pinning feature? What does that mean?

Implementations of pinning can differ, but in general it means restricting or bypassing the default chain of trust.

i.e., in the iOS case, rather than accepting a certificate based on whether it's issued by a trusted authority with a root certificate that ships (or has been manually installed) on iOS, verify the cert. by checking very specific information in the certificate.

I believe AFNetworking's pinning feature works by bundling a *.cer file containing the public key of the certificate issued by your trusted signing authority, and rejecting certificates that don't include that precise public key.

Companies like Square use certificate pinning; it's a good idea.

—Nathan

[Luke Tupper]

Just make sure you have a reminder in your calendar to release new version of your app *before* your certificate expires!

--

[Nathan de Vries]

On 27 May 2013 17:04, Luke Tupper <ltu...@gmail.com> wrote:

Just make sure you have a reminder in your calendar to release new version of your app *before* your certificate expires!

I'm not overly familiar with the details, but I'm pretty sure that's only true if you use AFSSLPinningModeCertificate, and AFSSLPinningModePublicKey doesn't suffer the same problem.

—Nathan

[Sadat Rahman]

One way to get around having to update your app binary closer to when
the certificate expires, is to pin to a public key in the server's
certificate chain of trust. You are effectively pinning to one CA /
intermediary.

Also, you might want to only enable pinning on RELEASE / app store
builds only, so that network introspection tools like Charles or Burp
can still work with your DEBUG builds.