Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Possible BGP hijack of 1.1.1.1

bgpstream.com

Post reply on HN
Print view View original

151–158 of 158 posts

Re: Possible BGP hijack of 1.1.1.1

#151

Post by amaccuish »

peterwwillis wrote: post #132
amaccuish wrote: post #122

Earlier quoted context omitted.

Ok ye the CA system isn't great, but as far as I'm aware, letsencrypt do DNS queries from multiple POPs, so that the route would have to propagate extremely widely to convince them to issue a cert.

A representative of LE commented on HN recently that they do not verify from multiple POPs. But even if they did, that would not stop this attack. There are hundreds of CAs, and not all of them are going to verify from multiple POPs. You only need your attack to work on one CA for it to be effective against every client on the web. Even if all CAs verified from multiple POPs (not likely) the attacker will just increa…

Thanks for that, I had no idea! I stand corrected :)

Re: Possible BGP hijack of 1.1.1.1

#152

Post by tialaramex »

peterwwillis wrote: post #149
tialaramex wrote: post #142

Earlier quoted context omitted.

"would take about 20 seconds, thanks to Let's Encrypt" Let's Encrypt does not offer certificates for IP addresses. They choose only to offer DV certificates using methods 3.2.2.4.6 and 3.2.2.4.7 How much of your hypothetical half hour will you spend trying to figure out why your chosen ACME client reports "Policy forbids issuance" when asked for an IP address? As to who is staring at CT logs, well there's the fun thi…

BGP allows anyone to issue fake certs, so it does have a relationship to web PKI. And sure, if you have a couple billion dollars, you can set up fancy infrastructure and response teams to monitor the whole web (that you are aware of, that participate in CT) for a strangely-issued cert. Or you could just get a cert issued by the CA you normally use. In which case, now we have to track some kind of "customer number" pe…

No, you wouldn't use a "customer number". The usual approach taken for these genuinely concerned outfits goes like this:

1. Agree contractual terms with particular Certificate Authorities in which all certs for names in your hierarchy need explicit approval from your security people.

2. Set DNSSEC-secured CAA records for your names forbidding issuance by other Certificate Authorities.

This funnels requests from hypothetical bad guys into your security people, which is exactly what they don't want. It loses you the shiny capability to do "spur of the moment" issuance, but presumably if you want these sort of terms the phrase "spur of the moment" causes you to start writhing and clutching your throat anyway. Insider threats will usually be much _worse_ than outsiders.

As to things being "specific to a particular browser" we can't and don't want to be able to force, say, Microsoft and Apple to do things just because everybody else decided they're a good idea.

The same with the trust store programmes. I can't make Microsoft take this seriously, but Microsoft can't make me use their SChannel and associated trust store. Maybe you have a lot more pull with Microsoft than I do.

If we're in a world where the "easiest" way to get a bogus certificate is now to do global BGP hijack of an entire /24 then I think we're on the right track.

Re: Possible BGP hijack of 1.1.1.1

#153

Post by tialaramex »

peterwwillis wrote: post #132
amaccuish wrote: post #122

Earlier quoted context omitted.

Ok ye the CA system isn't great, but as far as I'm aware, letsencrypt do DNS queries from multiple POPs, so that the route would have to propagate extremely widely to convince them to issue a cert.

A representative of LE commented on HN recently that they do not verify from multiple POPs. But even if they did, that would not stop this attack. There are hundreds of CAs, and not all of them are going to verify from multiple POPs. You only need your attack to work on one CA for it to be effective against every client on the web. Even if all CAs verified from multiple POPs (not likely) the attacker will just increa…

There aren't really "hundreds" of CAs in a sense that matters here.

Last time somebody insisted on this I actually counted, I forget the answer I got, but it's less than three figures.

You can get a bigger number if your idea of "effective against every client on the web" is "It works in Internet Explorer". Microsoft is very... liberal in accepting new CAs controlled by corporate or sovereign entities.

But if you expect "every client on the web" to include Chrome on Android phones, Safari on iPhones and Firefox everywhere, not just Internet Explorer, then you're talking about dozens, not hundreds, mostly because of the work done by Mozilla.

And most of those CAs are fairly small. Forget a nice API you can just make an HTTP request to and get your certificate in seconds, some of them are going to expect you to wait until business hours and talk to them on the telephone.

Re: Possible BGP hijack of 1.1.1.1

#154

Post by floatingatoll »

otterlicious wrote: post #90
floatingatoll wrote: post #61

Earlier quoted context omitted.

Is there a CAA equivalent for ARIN assignments?

Not yet. :-( https://tools.ietf.org/html/draft-shoemaker-caa-ip-01

Thank you for pointing this out. This is exactly what I’d hoped might exist someday.

Re: Possible BGP hijack of 1.1.1.1

#155

Post by knorker »

dice wrote: post #86
padiyar83 wrote: post #81

Earlier quoted context omitted.

Usually upstream ISP providing transit accepts only a valid set of prefixes that they have agreed to advertise on the public internet from an ISP customer, they enforce a policy on the ingress to make this happen. Idea being, if the customer ISP ends up advertising an incorrect prefix, then the impact is only localised to his ISP and not to the whole world. But some ISPs don't follow this and implicitly trust the cus…

>Usually If only... BCP 38[0] is nowhere near usual. Lots of networks, including some very problematic big ones ( cough Hurricane Electric cough ), do not implement it as a matter of course. The AWS Route53 hijack last month which resulted in downtime for a number of sites plus a six figure coin theft[1] could have been prevented by adequate filtering. 0: https://tools.ietf.org/html/bcp38 1: https://arstechnica.com/i…

Uhm, BCP38 is about forwarding, not the BGP control plane

Re: Possible BGP hijack of 1.1.1.1

#156

Post by Lennie »

dharmab wrote: post #43
czbond wrote: post #7

Earlier quoted context omitted.

1.1.1.1 is a DNS resolver that does not track activity. A BGP compromise means that someone could have compromised it and redirect/intercept traffic of those trusting it to be Cloudflare.

A BGP attack does not compromise the destination host. It reroutes (some) traffic destined for the host. Any traffic using TLS to establish destination authenticity (e.g DNS TLS, DNS over HTTP) or content authenticity (e.g. DNSSEC) would detect the attack, while other types of traffic (traditional DNS) could be exploited.

"Any traffic using TLS to establish destination authenticity (e.g DNS TLS, DNS over HTTP)"

Well, unless you can also fool Let's Encrypt from all their locations around the world. Then you can get a Let's Encrypt certificate.

Re: Possible BGP hijack of 1.1.1.1

#157

Post by Lennie »

Latteland wrote: post #145
jpollock wrote: post #82

Earlier quoted context omitted.

I'm sorry, I went for brevity because someone was asking for possible impacts. If I were using 1.1.1.1 as a DNS server and saw this news story, I would change to a different DNS server until the problem was resolved. My goal was to provide actionable information quickly. I never said it was specific to Cloudflare. :) It is specifically a mistake which would break an assumption - that putting 1.1.1.1 into your resolve…

Okay, thanks for your polite explanation.

If you use your providers resolvers you would be very unlikely to have this problem (it's not likely someone will re-route the traffic on the network of the provider themselves).

Re: Possible BGP hijack of 1.1.1.1

#158

Post by solotronics »

TheAceOfHearts wrote: post #148
solotronics wrote: post #120

Large companies misuse "unassigned" space all the time. I have heard engineers at my work propose using the non public routed DOD /8 before. Not on my watch!

If you happen to know why, could you explain their reasoning? In what ways are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 insufficient?

I help design one of big 3 cloud providers and we're about to run out of private space for customer IPv4. We are addressing this is in a number of ways but I think others have run into this same issue.
Post reply on HN