1

We have a mobile app that connects to our server via RESTful HTTPS web services. We also have an attacker who correctly emulates our app in communicating with our server. We therefore assume that our attacker is able to observe and decrypt the app's traffic using a tool such as Fiddler.

As I understand it, Fiddler inserts a certificate in the middle and acts as a proxy. Fiddler is able to provide the attacker a decrypted version of the data stream.

Should certificate pinning remove the ability for an attacker to observe the HTTPS traffic? With our mobile app in the wild, I have to assume the app can be installed on a rooted/jail-broken device.

Edward Barnard
  • 672
  • 6
  • 17
  • 1
    Does https://security.stackexchange.com/questions/72147/intercepting-ssl-traffic-on-android-app answer your question? – Neil Smithline Sep 14 '15 at 18:17
  • 1
    I believe my answer below responds to the updated question. Are you looking for more? – Neil Smithline Sep 14 '15 at 18:44
  • @NeilSmithline it does. Code on GitHub is good enough for me! – Edward Barnard Sep 14 '15 at 18:44
  • This is going to be off-topic from your question, but HTTPS protects the *channel*. Any data received by the client can be seen in the clear. If you need to protect the data (and not the channel), then you need to encrypt the data, not the channel (although encrypting the channel might be appropriate, too). – schroeder Sep 14 '15 at 18:45
  • @schroeder, I agree with that statement (https protects the channel) but contradicts Neil's statement yesterday http://security.stackexchange.com/questions/100129/what-to-do-when-you-can-t-protect-mobile-app-secret-keys (see the accepted answer) to trust TLS. The channel is protected but I have two more hurdles: 1, protecting the data, and 2, trusting the sender of that data. 1 can be encryption, but 2 is difficult! – Edward Barnard Sep 14 '15 at 18:58

1 Answers1

5

Per this answer, cert pinning can be bypassed on a rooted Android device or jailbroken iOS device.

I would go on to state that I think that your approach of trying to secure your application by adding client-side security is doomed to fail. While you can raise the bar of having your application examined via obfuscation and other tricks, as there's no physical security, you can't secure the client.

You need to make your API sufficiently strong to withstand attack from any client. The only alternative is to maintain physical control over the clients to ensure they are secured (rather awkward in a mobile app).

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55