Abstract
Security vendors love the man-in-the-middle attack. It’s the boogeyman of every TLS marketing page. Some shadowy figure intercepting your traffic, reading your secrets, stealing your data.
A man-in-the-middle attack is when an attacker positions themselves between two parties on a network to intercept the traffic flowing between them. In the context of TLS, that means an attacker who can present a valid certificate can read everything in plaintext and proxy it on to the real server.
But when was the last time you actually heard about one happening? Not a phishing attack. Not malware. Not credential stuffing. An actual man-in-the-middle interception of a TLS connection in the wild.
The Verizon 2025 Data Breach Investigations Report analyzed over 22,000 security incidents. Credential abuse accounted for 22%. Ransomware showed up in 44% of breaches. Phishing was in 16%. The “Adversary-in-the-Middle” is less than 4% of incidents, and the vast majority of those are real-time phishing proxies like Evilginx, not someone intercepting TLS connections with stolen certificates.
The attack everyone worries about is the one that almost never happens.
A stolen private key doesn’t get you very far
Let’s say the worst happens. An attacker steals a server’s TLS private key. Maybe they exploited a vulnerability. Maybe they found it in a git repo (please don’t do this). What can they actually do with it?
If you’re running any modern TLS configuration, less than you’d think. Perfect Forward Secrecy means a stolen private key can’t decrypt recorded traffic. Not past sessions or any future sessions. The “record now, decrypt later” scenario is dead for any connection using forward secrecy, which is now about 94% of the web.
What a stolen key can do is let an attacker impersonate your server. They can present your real certificate, complete a valid TLS handshake, and proxy traffic onward to the real server, without any browser warnings.
But there’s a massive catch: To impersonate your server, the attacker has to intercept the connection before it reaches you. They need a man-in-the-middle network position.
Getting ‘in the middle’ is the hard part
The difficulty of getting “in the middle” of a TLS connection varies enormously depending on where the attacker is and who they’re targeting. The spectrum runs from trivially easy to requiring the resources of an intelligence agency.
On a local network, it’s embarrassingly simple. ARP spoofing requires nothing more than a laptop on the same network and a free tool like Bettercap. One command redirects all traffic on that LAN through the attacker’s machine.
Evil twin Wi-Fi attacks are just as easy. A $200 pineapple device or a Linux laptop running hostapd can clone any network name and force nearby devices to connect. In 2024, Australian police arrested a man who ran fake Wi-Fi networks on commercial airline flights, harvesting credentials from passengers.
These attacks are real, but their scope is measured in meters, not miles. The attacker has to be physically present, on the same network, within radio range of their targets. That’s not a scalable attack against your production infrastructure.
DNS hijacking. Compromise a domain’s registrar account and you can redirect DNS queries to attacker-controlled servers. The most notable campaign, Sea Turtle, hit over 40 organizations across 13 countries by going after DNS registries directly. Cisco Talos assessed it as nation-state backed. They didn’t bother stealing private keys. They didn’t need to. They hijacked DNS and got fresh certificates from public CAs.
BGP hijacking. BGP is how internet routers decide where to send traffic. It runs on trust, with no built-in authentication. If an attacker controls a router at an ISP or hosting provider, they can announce false routes and reroute traffic through their own infrastructure. In 2018, attackers compromised a small Ohio ISP, hijacked Amazon Route 53 address space, and redirected MyEtherWallet users to a phishing server for two hours. They stole $150,000 in crypto. The attackers’ wallet already held $27 million. Not a casual operation.
Physical backbone taps are pure nation-state. GCHQ’s TEMPORA program tapped over 200 submarine cables. Hundreds of millions of dollars. Cooperation from telecom providers. You’re not defending against this.
Your business is probably not getting BGP-hijacked by a foreign intelligence service.
What actually compromises your TLS connections
The attacks that actually compromise TLS connections happen at the endpoints.
In 2015, Lenovo shipped consumer laptops with Superfish, a pre-installed root CA that intercepted all HTTPS traffic to inject ads. Every affected laptop shared the same private key, protected by the trivially extracted password “komodia.” Once that key leaked, anyone on the same Wi-Fi as a Lenovo owner could silently intercept their banking, email, everything. Dell did the same thing months later with eDellRoot. A root certificate, bundled with its private key, that would reinstall itself if you deleted it.
This is the threat model that actually matters for most organizations. If an attacker compromises a user’s endpoint through malware, phishing, or a supply chain attack, they can install whatever root certificates they want. They don’t need your server’s private key. They don’t need network position. They own the device, so they own the TLS trust chain on that device.
The Verizon DBIR data backs this up. For small and medium businesses, 88% of breaches involve ransomware. System intrusion, social engineering, and basic web application attacks dominate the landscape. Stolen-key MITM doesn’t make the list.
“So I don’t need to protect my private keys?”
Of course you do. They’re still secret, just not life-or-death important.
A compromised key can’t decrypt past traffic, but it could be used for targeted network impersonation. That’s a real risk, just not the five-alarm emergency.
The right response is proportional security. Encrypt keys at rest. Limit who and what can access them. Rotate them regularly. Use short-lived certificates so a compromised key has a smaller window of usefulness.
That’s exactly how we approach it at CertKit. Private keys in our database are encrypted using a key stored in our credential system combined with a salt compiled into the application. Decrypting them requires compromising both, independently. Agent communication is protected by agent-specific keypairs negotiated during authorization on top of TLS 1.3. No shared secrets between agents.
And for organizations that don’t want private keys leaving their network at all, we’re building the CertKit Gateway. Gateway runs on a server or container inside your infrastructure. It generates private keys locally and sends only the CSR to CertKit for validation and signing. The private key never leaves your network.
Spend your security budget on the threats that actually happen
If you’re running a mid-sized business, the honest threat assessment is that this is a minor risk. The chance of someone stealing your TLS private keys and then executing a man-in-the-middle attack against your users is vanishingly small. Not zero. But small enough that it should sit well below credential hygiene, endpoint protection, phishing training, and ransomware preparedness on your priority list.
If you’re running critical infrastructure or a high-value financial target, the risk is real enough to invest in dedicated monitoring, RPKI deployment, hardware security modules, and aggressive key rotation. CertKit Gateway is coming soon for exactly this reason.
For everyone else? Automate your certificates so they don’t expire. Use short-lived certificates so a compromised key has a smaller window of usefulness. And spend your remaining security budget on the attacks that actually happen.
CertKit automates certificate lifecycle management. Start monitoring your certificates for free, or talk to us about CertKit Gateway for on-premises key management.
Comments