Certificate pinning

Normally a TLS client trusts any certificate that chains to a trusted authority in the device’s store, which is what lets an interception proxy present its own certificate and read the traffic. Certificate pinning narrows that trust: the app is built to accept only a specific certificate or public key that its own developers chose, so a certificate from any other source, even a validly issued one, is rejected and the connection fails. This defeats the standard interception setup and raises the bar against a network attacker who has managed to insert a rogue certificate authority. It is a defence layered on top of the public key infrastructure, pinning to a known key rather than trusting the whole chain.

Pinning is a good control that is routinely oversold as a wall. It runs on the device, and the device is under the tester’s or attacker’s control, so on a rooted or jailbroken handset the pinning check can be hooked and bypassed with common instrumentation, and the traffic inspected as if pinning were not there. From the offensive side it is an obstacle, not a stop: it changes the effort, not the outcome, for anyone with device access. The client’s real question is what the traffic behind the pin actually protects, because if the answer is a weakly authenticated API, then bypassing the pin exposes the same weakness the pin was hiding. Relying on pinning to compensate for a weak backend is the mistake.

We report whether pinning is present and, honestly, whether it was bypassed, because on a controlled device it usually can be. The more important finding is what the inspected traffic reveals once we are past it: the authentication, the data, the API weaknesses the pin was standing in front of. Where the app leans on device-side defences such as root and jailbreak detection or mobile app attestation together with pinning, we test the combination against a controlled device. This is part of how we test pinning and the traffic behind it.