4 ms·
This is a good opportunity to assess what parts of your own online activity could be impacted by an attacker in the middle (assisted by a BGP leak or otherwise)
by 8organicbits 9mo ago
This is a good opportunity to assess what parts of your own online activity could be impacted by an attacker in the middle (assisted by a BGP leak or otherwise) and, if you're a service provider, how you can protect your customers.
At first pass you probably use HTTPS/TLS for the web, and you know that you shouldn't click through invalid certificate warnings. So the web, tentatively, looks pretty safe.
Email jumps out as vulnerable to eavesdropping, as we largely use opportunistic encryption when transferring messages between mail servers and an on-network-path attacker can use STARTTLS stripping or similar techniques. Most mail servers happily send using cleartext or without validating the TLS certificate. Check that you and your counter-parties are using DNSSEC+DANE, or MTA-STS to ensure that authenticated encryption is always used. Adoption is still quite low, but it's a great time to get started. Watch out for transactional email, like password reset messages, which virtually never validate encryption in transit (https://alexsci.com/blog/is-email-confidential-in-transit-yet/#whats-the-impact https://alexsci.com/blog/is-email-confidential-in-transit-ye... ; instead use multi-factor encryption).
TLS certificates themselves are at risk, unfortunately. An attacker who controls the network in-and-out of your DNS servers can issue domain-verified certificates for your domain; even removing protections like CAA records. DNSSEC is the classic solution here, although using a geographically distributed DNS provider should also work (see multi-perspective validation). Certificate transparency log monitoring should detect any attacker-issued certificates (a review of certificates issued for .ve domains would be interesting).
Ideally, we should build an internet where we don't need to trust the network layer. A BGP route leak would be a performance/availability concern only. We're not there yet, but now is a great time to take the next step in that direction.
- tptacek 9mo agoAttackers hijacking domains to get certificates issued are generally hijacking registrar accounts, which DNSSEC doesn't help with, which is probably one of the many reasons DNSSEC is so rarely deployed.
- 8organicbits 9mo agoWe know, you've told us many times. But that's not the context of the thread.
- tptacek 9mo agoI'm not fixated on any particular argument, but the preceding comment offers network security advice as if it were best common practice, and it is not in fact that. That's all! Not a big thing.
- 8organicbits 9mo agoI would be interested in your take; if you had to distrust the network, how would you protect HTTP, SMTP, DNS, and TLS certs? I suspect your answer isn't DNSSEC, but I'd be interested to hear what you would use instead. The European answer seems to be DNSSEC, considering adoption rates there. (edit: should be "includes" not "be", it's one of the tools they use).
- tptacek 9mo agoDNSSEC adoption on major European properties is also quite low! Try a bunch of domains out (`host -t ds <domain>`). There are more in Europe, of course, but not very many, at least not major ones. My hypothesis, I think strongly supported: the more mature your security team, the more internal pushback against DNSSEC.
- 8organicbits 9mo agoSure, I'll do some homework for you. I just took the latest Tranco top million list (7N42X) and scanned the top thousand .cz domains. 61% of the top 100 .cz domains have DS records as do 50.6% of the top thousand .cz domains. That matches what others have been reporting and doesn't seem "quite low" to me. If you're interested in talking about something other than DNSSEC, I would be interested in your thoughts here.
- 9mo ago
- David_Osipov 9mo agoThere is a nuance here for Cloudflare users that makes this problematic. While analyzing the Jabber.ru incident (which used this exact BGP->TLS vector), I discovered that Cloudflare's "Universal SSL" actively injects permissive CAA records that override user-defined restrictions. If a user sets a strict accounturi CAA record (RFC 8657) to lock issuance to their specific account—specifically to prevent BGP hijackers from getting a cert—Cloudflare's system automatically appends a wildcard record alongside it to keep their automation working. Because CAs accept any valid record, this effectively nullifies the protection. It creates a situation where you think you have mitigated the BGP risk via DNS, but the vendor has silently reopened the door. I wrote up the technical analysis of this override behavior here: https://david-osipov.vision/en/blog/cybersecurity/cloudflare-ssl-mitm-flaw-2026/ https://david-osipov.vision/en/blog/cybersecurity/cloudflare...