[mschuster91]

> Compared to just about any other attack vector on the internet, BGP hijacking is among the least likely to impact most people.

But when it happens, it impacts massive amounts of people - about once a year on average [1]. Sometimes it's censorship gone bonkers, sometimes it's likely a three-letter agency, sometimes it's fat fingers, and sometimes it's cybercriminals attempting to loot cryptocurrency wallets.

[1] https://en.wikipedia.org/wiki/BGP_hijacking

[phicoh]

BGP hijacking also works on a small scale. If you don't use DNSSEC and somebody hijacks the prefix(es) that host your DNS, they can obtain a letsencrypt certificate and redirect all your traffic.

If you don't have a CAA record and somebody hijacks the prefix(es) where your webserver is hosted, they can also obtain a letsencrypt certificate and redirect your traffic.

[tptacek]

If you do use DNSSEC, an attacker that controls BGP can still misissue certificates.

[phicoh]

That's not correct. If you set the CAA correctly you can limit certificates to for example letsencrypt and dns validation.

An attacker can get around that if a CA does not use DNSSEC validation to check the CAA. But that would be a problem with the CA system.

[tptacek]

I'm not sure you're following. An attacker who controls BGP controls, for some small (or large) section of the Internet, the meaning of IP addresses. No DNS validation gets you around that.

LetsEncrypt does in fact do things to mitigate this attack, but they have nothing to do with DNSSEC: they do multi-perspective lookups, so you'd need Internet-wide routing control.

[phicoh]

It seems you miss something, maybe because you don't consider DNSSEC as something that gets actual use.

With DNSSEC, somebody can reroute traffic all they like, they cannot generate fake DNS responses that are DNSSEC valid for DNSSEC secured victim domain. So if the CAA record is properly set to only allow the dns-01 validation method for ACME, there is simply no way to obtain a false certificate even if the attacker controls all of BGP.

[foobiekr]

That issue isn’t a dnssec problem, it’s that Let’s Encrypt was not familiar with the route hijacking threat model. It was pointed out early to them and they ignored it.

[rixthefox]

Why blame LetsEncrypt? Instead blame the operators who are refusing to address basic network security.

I run a network, we do the whole shabang of RPKI, DNSSEC, and CAA. It sounds a whole lot like operators who refuse to address clear security issues. LetsEncrypt is not to blame when someone spoofs your address space.

LetsEncrypt is not a LIR/RIR, their business is not IP resources but SSL certificates. They are a CA. They have no tools available to them to address that problem.

[immibis]

Because Let's Encrypt is the CA that hands out certificates without actually verifying identity.

[phicoh]

If you set the CAA correctly, then letsencrypt will limit validation to the dns method. Together with DNSSEC that is enough to prevent issuing certificates in case of a route hijack.