As per the recent jabber.ru MITM attack:

The attacker has issued several new TLS certificates using Let’s Encrypt service which were used to hijack encrypted STARTTLS connections on port 5222 using transparent MiTM proxy.

My understanding is that (allegedly) the hosting provider (Hetzner) simply rewired the networking to perform an ACME protocol re-run with Let's Encrypt. This got them their own certificate, allowing them to perform the wiretapping.

Say a powerful adversary (such as a hostile government) wants to intercept TLS protected traffic to a site. My understanding is that they could then do so even without coercing the hosting provider. For example, they could take control of network-wise entry-points to the host and repeat the DV certificate ACME HTTP challenge with Let's Encrypt. Alternatively, producing a valid certificate may be done via the DNS challenge ACME challenge.

Given these (and other) options, what's the most likely way (e.g. least costly, or least operationally complicated) a hostile government would attempt to trick ACME into generating a certificate?

Note: certificate transparency would allow detection, which is good, but may not always happen.

  • 2
    I asked a similar question when Let's Encrypt was new. The answer was: Yes, anyone who can MITM your server at the server end can get a valid certificate for your server. ACME (and by extension now, TLS) really only protects you from malicious actors near the client, distant from the server, and from actors who can't perform a full MITM. Commented Dec 17, 2023 at 16:20
  • @user253751, the answers you mentioned are outdated, see my answer here for more details.
    – lukasl
    Commented Dec 18, 2023 at 0:27

2 Answers 2


Generating the certificate is not sufficient for a successful attack. The adversary actually needs to be able to use the certificate to impersonate the server to the client, i.e. the client needs to resolve the target domain in a way which results in connecting to the adversary instead the true server.

This basically leaves two ways for the adversary - get control of the DNS to create a new path to the server or insert itself into an existing path to the server. Since ACME DV validations are done from multiple points in the world it is not sufficient for this control to be only specific to some clients, i.e. either the adversary needs to get control of the primary DNS (or the DNS configuration) or it needs to intercept the traffic near the original server.

Which of the options is easier depends on the situation. If the DNS server is in a different jurisdiction it might be too hard to get control of it and a similar problem exists for intercepting the traffic to the server.

Assuming that both DNS and server are in the same jurisdiction, then it might be better to just intercept the traffic to the original server and leave the DNS alone. This way the attack is less noisy: changes to the DNS are public and thus will be easily noticed by someone watching. Man in the middle in front of the server instead is not publicly visible and thus more stealth. Also it is sufficient to solve the HTTP ACME challenge, which means the adversary can easily get the certificate.

Of course, someone in control of the original server can monitor what certificate is served for this server from the internet and compare this with the certificate actually configured at the server. So they might detect the attack early. But, the general public has no way to make this comparison, in contrary to detecting changes in the DNS setup.

  • The general public can notice both changes in the DNS setup and in the used certificate (including public key changes). In both cases, the general public cannot know if these changes are legitimate or an attack, but the site owner knows. Therefore, there seems to be no fundamental difference in the observability of both attacks.
    – lukasl
    Commented Dec 16, 2023 at 20:53
  • 3
    @lukasl: Changes in the certificate happen regularly, like at least every 3 month with Let's Encrypt. So from the outside perspective there is nothing unusual with this. Changes in the DNS are typically rare, so it is more suspicious. Commented Dec 16, 2023 at 21:16
  • 1
    The typical certificate renewals are regular. Deviations from the regular pattern should also be rare and as suspicious as DNS changes. Either of those changes typically wouldn't be enough to assume that a site was compromised though, or to ask the site owner if these were legitimate.
    – lukasl
    Commented Dec 16, 2023 at 21:52
  • @lukasl: Since the certificate renewals are done in regular intervals the adversary could plan to fit their attack into these interval in order to not concern public observers. Anyway, this is not about being totally hidden vs. obvious attacks, but about less obvious and more obvious attacks. In any case the best protection would be to for the site owner to monitor what certificates are visible from the public. CAA (as you proposed) with accounturi can also be effective if the CA actually supports this - for the public it is not visible what account was used to create the certificate. Commented Dec 16, 2023 at 22:05
  • 1
    @Michael: I'm not sure if this is really that suspicious if there are multiple entries in the CT for the same domain. It's not unusual that systems with multiple locations get each their own certificate for a domain. One could also use a slightly different list of SAN - it is not unusual that domain owners have overlapping certificates either. Of course, the domain owner might notice, but they can already notice that the certificate shown to the internet is not the one they have configured. Commented Dec 20, 2023 at 17:29

With DNSSEC and ACME-CAA parameters enabled for a domain, an adversary can only obtain a certificate over ACME by taking over the domain through the registry (or taking over the whole registry, or the DNSSEC root keys). Therefore, any network-level MitM attack cannot help the adversary in this case.

If the hostile government can force the registry to transfer the domain, certificates obtained by this could only be detected with Certificate Transparency. Also, CAs aren't required to check DNSSEC, so network-level attacks would still be possible when the adversary finds and uses a CA that doesn't check DNSSEC, irrespective of the legitimately used CA.

See https://www.devever.net/~hl/acme-caa-live for a more detailed explanation that also discusses the referenced attack.

  • This is true but only true if the CAA record contains an accounturi which is allowed to get certificates for this domain or if the validationmethods disallow HTTP challenge. Otherwise the in-path adversary could use their own account with the same CA. Commented Dec 16, 2023 at 21:20
  • 1
    @Steffen Ullrich, if you are a cautious site owner, just add these parameters. If you are a cautious user, suggest the site owner to add these parameters. This should be much more effective than guessing if DNS or certificate changes are legitimate.
    – lukasl
    Commented Dec 16, 2023 at 22:01
  • The CAA record can also mandate use of DNS-01 (disallowing HTTP-01) ACME method, at least if LE has enabled that in production yet. Combined with DNSSEC, this makes it cryptographically impossible for a CA honoring the requirement to check CAA to issue a certificate to the attacker, unless the attacker has already managed to coerce a fraudulent DS record to be installed at some level of the DNS hierarchy. Commented Dec 17, 2023 at 3:19
  • 3
    Sadly CT does not yet record this information, but ideally CT logs would mandate inclusion of the full set of DNS records used to issue the certificate, including full signature chains for each. This would make it so that any certificate issued via coercion of a DNS actor, or by a misbehaving CA that did not properly check the DNS records, would carry irrevocable cryptographic proof of what party was at fault. Commented Dec 17, 2023 at 3:21
  • Hilariously; the withdrawn Public Key Pinning mechanism would have prevented even a government from getting a certificate that worked for returning users.
    – Joshua
    Commented Dec 17, 2023 at 3:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .