When the Attacker Is the Client: Defending Against MitM Attacks

Imagine you’ve built a secure mobile app. Your connections are encrypted, your infrastructure is hardened, and your team sleeps well at night. Then a security researcher shows up with a rooted Android phone, a free proxy tool, and your entire API traffic laid out in plain text.

This is the man-in-the-middle (MitM) problem and it’s especially tricky because the attacker isn’t always lurking on a coffee shop Wi-Fi network.

For mobile applications, you’re usually concerned about MitM, but also man-in-the-client attacks where the attackers can control the endpoint device and try to intercept the communication to the server. Sometimes they’re sitting at a desk, deliberately trying to reverse engineer how your app talks to your processing server. No single security control stops that. What does work is layering the right defenses for the right use case: certificate pinning, white-boxed end-to-end encryption, and white-boxed mutual TLS are good options. Here’s what each one does, why it matters, and where it falls short.

Certificate Pinning: Your First Line of Defense

When your app connects to a server, it normally trusts any certificate issued by a recognized Certificate Authority. Certificate pinning throws that rulebook out. Instead, your app is hardcoded to only trust pre-configured specific certificates. If a different certificate shows up during the handshake, the connection is refused, full stop. Pinning is powerful, but it creates real operational headaches that you need to plan for. Certificate rotation is now your problem. If your pinned certificate expires and you haven’t pushed an app update first, legitimate users get locked out.

Determined attackers who also control the mobile application can bypass the certificate pin using rooted devices and dynamic analysis tools like Frida to bypass the pinning check. Pinning can make sense to meet compliance needs or as an additional layer of security against MitM attacks, but there are stronger approaches to counter MitM. It is especially important when the attackers directly control one of the endpoint devices.

White-box Cryptography for End-to-End Encryption: Protecting Keys When You Can’t Trust the Device

Standard encryption assumes that even if someone can intercept your traffic, they can’t read it because the keys are secret. But on a rooted device where the attacker can control one end of the encryption, that assumption breaks down. An attacker can dump memory, hook into your cryptographic library calls, and extract keys before or after encryption happens. White-box cryptography solves this by fusing the key and the algorithm together into a single, heavily obfuscated implementation. The key never exists as a standalone value in memory.

Using a white-boxed implementation of AES or similar algorithm to encrypt communications between mobile devices and the server in addition to the TLS layer can make it so that MitM attacks are unable to understand the data. The extra encryption will reduce performance, but there is a strong security benefit for this approach.

Mutual TLS: Making Sure Only Your App Can Talk to Your Server

In a standard TLS connection, only the server proves who it is, and your app checks the server certificate and decides whether to trust it. Mutual TLS (mTLS) flips this around, so both sides authenticate. Your app presents a client certificate during the handshake, and your server breaks communication with anything that can’t prove it holds the right one.

In practice, this means that even if a threat actor somehow bypasses certificate pinning, they still can’t reach your processing server without a valid client certificate. Threat actors will need to use a valid client or to extract the private key from the application. Certificate management at scale is hard. Issuing, rotating, and revoking client certificates for millions of users requires serious PKI infrastructure. It’s doable, but it’s not trivial. On rooted devices there is still a risk that a threat actor can extract the client certificate and private key to impersonate a legitimate app instance. This can be significantly improved with white-boxed implementations of signature generation algorithms with flexible key sizes like RSA SigGen or elliptic curve discrete logarithm algorithms like ECDSA which can embed the private key into the code so that it cannot be easily extracted.

Using Individually or Putting It All Together

Each of these controls could be used alone or combined. Certificate pinning stops proxy interception but can be bypassed on rooted devices and has operational issues with rotating certificates. White-box E2EE protects payload confidentiality even under active instrumentation but has a performance impact. mTLS ensures only legitimate app instances can connect, but private keys must be secured with hardware or white-boxed implementations, and certificates must be managed at scale.

Digital.ai can now provide certificate pinning and has FIPS certified white-boxed implementations to E2EE and mTLS approaches. E2EE alone might be sufficient for many use cases, or all the approaches can be layered together to maximize security.