Your app reduces interception and connection-tampering risk by trusting only the servers it expects, by noticing when the device or the app itself has been set up to intercept, and by giving your backend a way to recognise altered requests. Otukan combines certificate pinning with backup keys, proxy and user-certificate context, hooking detection on the functions that validate certificates, and request integrity signals. It covers the app’s own connections on Android and iOS. Corporate networks that inspect traffic, certificate rotation and recovery are planned with your team, so legitimate users stay connected.
Connection threats
Interception takes different forms, and each one leaves different evidence.
| Threat | How it works | Stopped by HTTPS alone? | Where Otukan acts |
|---|---|---|---|
| Invalid certificate | A network attacker presents a certificate the device does not trust | Yes, when the app validates properly | Strict validation for the app’s traffic |
| Added certificate authority | The attacker persuades the user or an administrator to trust a new authority | Not always | Pinning refuses keys you did not expect |
| Intercepting proxy | Traffic is routed through a proxy that decrypts and re-encrypts it | Not always | Pinning, plus proxy and certificate context |
| Hooked trust checks | A tool on the device replaces the app’s certificate checks | No | Hooking detection on validation functions |
| Manipulated session | A captured request is replayed or altered | No | Request integrity signals for your server |
Most successful attacks on a protected app do not break encryption. They persuade the app to trust the wrong party. That is where Otukan concentrates.
Per-platform behaviour
On Android, apps built for current platform versions do not trust user-added certificate authorities unless they opt in, and each app declares its rules in a network security configuration. On iOS, App Transport Security requires encrypted connections by default, and profile-installed certificates need explicit user trust. Otukan’s checks follow each platform’s own rules; neither platform’s behaviour is assumed for the other.
Control layers
Each layer covers a gap the others leave.
- Validation. The app’s own traffic uses encrypted transport with strict certificate checks, and fallbacks are refused. See connection hardening.
- Pinning. The app accepts only the keys your servers use. See certificate pinning.
- Integrity. Hooking detection and anti-tampering notice when pinning or validation is removed from the app or switched off while it runs.
- Context. Proxy, VPN and user-certificate settings reach your backend as risk context. See proxy detection.
- Server decision. Signals travel with requests, so your backend decides whether to serve a login or payment.
Traffic from third-party libraries inside your app is reviewed during onboarding, because not every library uses the app’s network stack.
Where the layers meet
A typical interception attempt shows how the layers support each other. An attacker installs a proxy certificate: pinning refuses it. They hook the pinning code: hooking detection reports the change. They patch the check out of the package: integrity checks see a modified release. At every step your backend hears about it, and the login or payment waits for a decision there.
Operations
Connection controls fail in public when they are not planned. Otukan treats operations as part of the product.
Legitimate enterprise networks
Some organisations inspect all encrypted traffic with their own certificates. You choose, per flow, whether such networks are allowed. Allowed networks proceed with the signal recorded; refused ones show users a clear message and a way forward.
Certificate rotation
Primary and backup keys are shipped together and changes follow an agreed schedule. Your infrastructure team knows which keys the app expects before any certificate is renewed.
Support and diagnostics
When a user reports that the app cannot connect, your support team needs to know why. Otukan records which layer refused the connection, whether pinning, validation or a policy on proxies, so support can tell a hostile network from a misconfigured one and give the right advice.
Recovery
If a key must be replaced urgently, the agreed plan says which backup takes over and how users on older releases are guided to update. Captive portals and expired certificates are handled with messages rather than silent failures.
Each control is verified in an authorised lab: an intercepting proxy and an added authority confirm the refusal and the signal, the same journey on a clean network confirms normal service, and install, update, sign-in and the payment or account flow are repeated, with versions, networks and the reviewer recorded. For wider context, return to mobile app security. For a structured way to evaluate options, see the man-in-the-middle prevention solution guide.