- Synacktiv showed in a lab that an open-source tool can read and change encrypted app traffic once a device trusts the tool's root certificate.
- Encryption protects the channel, but the device's list of trusted certificates decides who can sit in it. The padlock alone does not prove who is on the other end.
- Ask who can add root certificates to company devices, which apps pin certificates, and whether developers verify git signatures.
Most leaders treat the padlock in a browser as a promise. The traffic is encrypted, so it is private. A walkthrough from the security firm Synacktiv shows the condition attached to that promise. Encryption shields data from strangers on the network. It still depends on which certificates the device has been told to trust.
What Synacktiv demonstrated
Synacktiv's researchers had to inspect app traffic on Linux, Android and iOS during security assessments. They wrote a guide to mitmproxy. It is an open-source tool, written mainly in Python. It sits between an app and its server. It can analyse, change and replay the traffic that passes through.
The guide is a technique write-up. It does not report an attack on real victims. The git demo ran in what the researchers call a fully controlled environment.
How the interception works
The guide first describes two ways to put the tool in the path. In explicit mode, the device is set up to send its traffic to the proxy. Apps that ignore the device's proxy settings are missed, unless firewall rules force the redirect.
In transparent mode, the device is not told anything. Network rules on the path, such as iptables or nftables, steer traffic to the proxy. The proxy reads the domain name from the start of the encrypted handshake. It then forges a certificate for that domain.
The guide uses a third setup, a reverse mode, for its Mumble demo. We return to it below.
The forged certificate only works if the device trusts the proxy's root certificate. Synacktiv calls this the critical point when analysing network communications. The exception is an app that does no certificate validation at all.
Certificate pinning is the defence. An app that pins accepts only specific certificates for a domain. Interception then needs extra countermeasures.
Three demonstrations, three trust gaps
The first demo used git. The researchers pointed git at the proxy. They gave it their root certificate through an environment variable. They also noted that git lets users switch verification off entirely.
A clone of the nmap project produced three main requests. The researchers rewrote the last two so that git fetched a different project, Magisk, instead.
The researchers said the same method could return a modified nmap with a backdoor. The attack assumes the user does not check commit or tag signatures. Git does not validate those by default. The researchers suggest the same attack could be applied to a victim workstation with a permissive git configuration.
The second demo used Android. Since Android 7, apps no longer trust user-installed certificates by default. The researchers rooted a device with Magisk. They used a module called Cert-Fixer to copy user certificates into the system store.
They then intercepted a gRPC request from Google's location services. gRPC is Google's remote-call protocol, and it carries data serialized with protobuf, a binary format. They edited the latitude and longitude in flight. The phone's location requests resolved to the Eiffel Tower instead of the researchers' Paris offices.
The researchers add a limit of their own. Google uses other methods to find a location. A full study would need many more endpoints. Their point is how easily data can be changed once the proxy is trusted.
The third demo used iOS and the Mumble voice-chat app. Here the researchers ran mitmproxy in reverse mode. It listened on Mumble's standard port and forwarded traffic to their own Mumble server.
Mumble does not require certificate pinning. Users can host their own servers, so no fixed list exists. Messages are not encrypted a second time inside the TLS session. If the channel is compromised, the text can be read. One example is accepting a self-signed certificate.
The lesson for leaders
This shows that TLS is a promise about the channel. The channel is only as trustworthy as the device's list of trusted certificates. Whoever controls that list, and can route the traffic, can sit in the middle.
For defenders, that is a useful testing method. For anyone relying on the padlock alone, it is a reminder of the condition attached.
None of this is a new flaw in a product. It shows the effect of design choices. Pin certificates or not. Use one layer of encryption or two. Check signatures or skip them.
Questions to put to your teams
Ask whether developer machines verify commit and tag signatures. Ask which of your mobile apps pin certificates, and which cannot because users choose their own servers.
Ask whether any sensitive message relies on TLS as its only protection. Ask who may add a root certificate to company laptops and phones. Ask whether anyone reviews that list.
The padlock tells you a connection is encrypted. It does not tell you who is on the other end.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Synacktiv.
