0

We have implemented and successfully verified client side certificate checking with an iOS7 app and Apache server. The question is: is this enough to counter a MITM attack or should we also implement some kind of certificate check (like outlined here https://web.archive.org/web/20140217232458/http://www.inmite.eu/en/blog/20120314-how-to-validate-ssl-certificates-iOS-client )

Adi
  • 5,089
  • 6
  • 33
  • 47
  • 1
    I'm not familiar with how this is done in iOS, but the article you link to talks about a MITM attack that relies on installing the attacker's CA cert in the device's trusted CA list. This really shouldn't be possible. If you're not in control of your device's CA list, you're probably not in control of much on your device (assuming iOS isn't flawed in that respect). – Bruno Nov 05 '13 at 19:41

1 Answers1

1

No, but authenticating that the identity in the certificate is one that you want to talk to does. Only the application can do this. It is a much under-appreciated and much omitted requirement of systems using SSL.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thanks for the definitive answer. We are doing that now too. I've noticed AFNetworking certificate [pinning mode](https://github.com/AFNetworking/AFNetworking/blob/master/AFNetworking/AFSecurityPolicy.m#L200) does a byte-for-byte comparison with incoming certificates and we are now doing similarly. –  Nov 06 '13 at 23:46
  • 1
    That's entirely the wrong approach. You authorize the entity that owns the cerfificate, not the certificate itself. The PKI authentication process ensures that the subject DN in the certificate identifies the peer. You should be authorizing based on the subject DN, not the entire certificate. – user207421 Nov 15 '13 at 03:42