Some comments regarding the recently discovered Interception of HTTPS/TLS/SSL traffic by a state actor in Germany.

Ten years ago, in 2013, the IETF #88 (which is the standardization body of the Internet) declared that the Internet surveillance program by the NSA (Snowden leak) constitutes an "Attack against the Internet and the IETF". Ten years later, the Internet is still under attack. HTTPS is not safe. You browsing the Internet, doing online banking, forming a political opposition, or being a journalist, is not safe.

1. The interception happened at layer-7 of the ISO/OSI model. This is odd (for a state actor). Such an attack can be detected by observing the changing TCP counters (SEQ/ACK) and the TTL. The intercept should have been done at layer-3 and without changing the IP/TCP/TTL counters ...or the size of the packets.

2. The attacker made several mistakes. The most noticeable is the expired certificate, but also a bad CommonName (CN), TTL mess-up, network outage, and not utilizing a fully transparent proxy ...

3. The attacker messed up the ARP table.

4. The attacker did not steal the original certificate/key from the server.

The interception does not have the typical hallmarks of a professional state actor.

Recommendations for server admins and app developers:

1. Do not use a public Certification Authority. If you do, then the app/client should not load the entire CA bundle. It should only load the one CA that was used to sign the server's certificate.

2. Make use of Certificate Transparency (CT) and get notified when your issuer or another Certification Authority (CA) issues a new certificate for your domain name. Most modern browsers (but not all) reject any certificate that is not logged by CT. Most (all?) other TLS applications will accept unlogged certificates.

   Other cloud services offer to regularly check your TLS services for a changing certificate. The attacker could easily decide to 'not intercept' the traffic from those crawlers/spiders.

   Ultimately, it should be the client software that yells a warning when the server's certificate changes.

3. Certification Authority Authorization (CAA) is a voluntary option and it is not enforced by the browser or client. This will not happen anytime soon.

4. Make the server's certificate sticky. The client should yell a warning when the server's certificate changes, even if the new certificate is valid....and especially if the old certificate is not due for renewal. ???Is there a browser plugin that does this??? THIS CAN HAPPEN SOON*.*

5. Watch the TCP/IP/TTL counters. An incoming TCP with TTL>=62 means it's not a real user but an attacker/MitM connecting to your server 🤗, (we pity the state actor for messing this up).

6. Store your server's key on an encrypted volume that does not auto-mount. To which only YOU have the password, (not AWS encrypted EBS, to which AWS holds the password). It's a pain because the server won't restart automatically after a reboot: It needs an admin to enter the password - but that's the world we are living in. Get used to it.

There is a wider problem: Attacks always get better. Here are two problems to ponder about:

1. State actors have access to the underlying VPS storage device (volume). They don't need to create a 'new' certificate using LetsEncrypt. Instead, they can steal the existing one from the server without the server noticing it, and without having to log in to the VPS server. ???Why didn't they??? THAT IS THE ATTACKER'S OBVIOUS NEXT MOVE.

2. Cloud Service Providers use EDGE servers (Cloudflare and all others). They do 'Interception' as a feature: When you configure a cloud server with 'edge' support then your server's key is loaded to the Cloud's edge. All traffic is then decrypted at the edge (aka the "TLS border gateway"). E2EE is dead. It's more like 'encrypted to the first EDGE and then all is cleartext (and readable by the Edge-Provider and state actors) until the traffic reaches your server'.

This type of attack, (when the server's private key is stolen), is hard to defend against, but easily performed by an attacker. One way to make this attack harder:

1. Enforce Client authentication with client keys (like SSH does). Don't use passwords. Ever.

2. Compare the ECDH shared-secret that Alice and Bob negotiated during kex (KexEchange). When under MitM attack, this shared-secret will be different for Alice and Bob (when normally it would not): Malice, sucks to be her, cannot guess the public part of the ECDH pair. She needs to generate her own public ECDH pair, one for the Alice-side, and another one for the Bob-Side of the intercepted connection. Malice will intercept with the two different shared-secrets. Alice and Bob will end up with a different shared-secret when under attack.

Other: https://www.devever.net/~hl/xmpp-incident

Like talking about cryptography and security? We get a hard-on every time. Join us on Telegram: https://t.me/thcorg.