3 ms·

Can you describe what this means?

userbinator 9y ago
Hardcoding the exact certificate they expect, to prevent MITM attacks. Of course, not every MITM is malicious, as this item shows.
- bigiain 9y ago
  Then Geotrust, in a petulant hissyfit, email ~20,000 of their customers private keys to DigiTrust - and the carefully laid plans of updating the app with newer ssl certs pinned 12 and 6 months in advance of expiry are - ummmm - revealed to be flawed... Hilarity ensues.
  - nstj 9y ago
    Well, the certs don't _have_ to be shipped with the app, there are workarounds to refresh the certs without sending out a whole new app binary.
    - bigiain 9y ago
      Yep - but guess what wasn't done in this case... (Yes, this is a still-trying-to-fix-it real world event... Glad it's not my problem, just one I hear about from people I used to work with...)
      - jmiserez 9y ago
        If you do pinning, you could just as well use a self signed cert for your API and pin that. If your API is not just used for the app, add a private proxy/load balancer that uses your pinned cert.
nstj 9y ago
Charles works by sitting between a server and a phone. It decrypts traffic from the server, displays this to the user to 'inspect', and then re-encrypts the traffic to be sent to the phone. It re-encrypts the traffic using its own SSL certificate (technically a CA, but no need to get bogged down in details). In many modern apps, code has been added such that an app will only accept traffic which has been encrypted by the original server certificate (ie: the Uber iOS app will only accept traffic which has been encrypted by a certificate from www.uber.com). When Charles attempts to sit between this traffic, the app will not allow network connections, and thus no traffic can be inspected by Charles. This procedure of an app only permitting traffic encrypted by a predefined certificate is known as "certificate pinning" or "pinning" for short. It is becoming more and more common for native apps.
- dannyw 9y ago
  The reason for this is primarily to protect against MITM attacks by a hostile network and rogue CA, enterprise proxies, etc.

Hardcoding the exact certificate they expect, to prevent MITM attacks. Of course, not every MITM is malicious, as this item shows.

bigiain 9y ago
Then Geotrust, in a petulant hissyfit, email ~20,000 of their customers private keys to DigiTrust - and the carefully laid plans of updating the app with newer ssl certs pinned 12 and 6 months in advance of expiry are - ummmm - revealed to be flawed... Hilarity ensues.
- nstj 9y ago
  Well, the certs don't _have_ to be shipped with the app, there are workarounds to refresh the certs without sending out a whole new app binary.
  - bigiain 9y ago
    Yep - but guess what wasn't done in this case... (Yes, this is a still-trying-to-fix-it real world event... Glad it's not my problem, just one I hear about from people I used to work with...)
    - jmiserez 9y ago
      If you do pinning, you could just as well use a self signed cert for your API and pin that. If your API is not just used for the app, add a private proxy/load balancer that uses your pinned cert.

nstj 9y ago

Charles works by sitting between a server and a phone. It decrypts traffic from the server, displays this to the user to 'inspect', and then re-encrypts the traffic to be sent to the phone. It re-encrypts the traffic using its own SSL certificate (technically a CA, but no need to get bogged down in details). In many modern apps, code has been added such that an app will only accept traffic which has been encrypted by the original server certificate (ie: the Uber iOS app will only accept traffic which has been encrypted by a certificate from www.uber.com). When Charles attempts to sit between this traffic, the app will not allow network connections, and thus no traffic can be inspected by Charles. This procedure of an app only permitting traffic encrypted by a predefined certificate is known as "certificate pinning" or "pinning" for short. It is becoming more and more common for native apps.

dannyw 9y ago
The reason for this is primarily to protect against MITM attacks by a hostile network and rogue CA, enterprise proxies, etc.