hunting-mobile-tls-pinning-and-trust-gaps

Hunting mobile TLS pinning and trust gaps: when the app trusts a network it should not

A mobile app talks to its backend over connections it treats as private, and that privacy depends entirely on the app rejecting any network position that would let someone read or alter the traffic. The app does that by validating the server's certificate against trusted anchors, refusing cleartext, and, for its most sensitive connections, pinning to a known certificate or key so even a trusted-but-wrong authority is rejected. The gap is any place the app accepts a network position it should reject: it trusts certificate authorities the user or a device profile added, it allows a cleartext or mixed connection, it disables or loosens validation for convenience, or it pins some connections but leaves an unpinned or fallback path a network attacker can take. The bug is not the absence of pinning everywhere; it is a sensitive connection the app treats as secure that an intercepting network position can actually read or alter. You hunt these by listing every connection and checking whether each resists a network attacker.

When to use

• A mobile app makes network connections it treats as private and you can observe its trust behavior.
• The app may trust user-added anchors, allow cleartext, or loosen certificate validation.
• Some sensitive connections may be unpinned, or pinning may have a bypassable fallback.

Scope check

Hunt transport trust gaps only on apps and networks you own or are authorized to assess, on test devices and accounts, interposing only on a network you control and never on real users' traffic. A confirmed gap exposes supposedly secure traffic, so keep every probe within scope. If you can't name the authorization, stop.

The loop

1. Establish whether each sensitive connection rejects an intercepting position first. For each connection the app treats as private, determine whether it validates the certificate against trusted anchors, refuses cleartext, and, where required, pins to a known certificate or key, so an intercepting network position is rejected, or whether some trust gap lets that position succeed. This is the false-positive killer: a connection that validates strictly and pins where it matters cannot be read by a network attacker, so its presence is not a finding. Name the accepted network position before claiming interception.