RPKI doesn't make BGP safe, it makes it safer. BGP hijacks can still happen.
RPKI only secures the ownership information of a given prefix, not the path to that prefix. Under RPKI, an attacker can still claim to be on the path to a victim AS, and get the victim's traffic sent to it.
The solution to this was supposed to be BGPSec, but it's widely seen as un-deployable.
This sounds "obviously bad" but the intricacies of routing aren't really my field, could you expand on why this is bad? (i.e. what specific bad things does it enable)
SCION is generally considered snake oil within the network operator community. Its weird single vendor for profit company that ships it's software, the fact that no router hw asic fwding supports what they want to do and then the general scummy inclusion of block chain / crypto as well as some "green washing" for PR hype.
Sure the swiss have their toy but no one is taking it seriously.
Hmm, I'd disagree. The fact that Anapaya Systems (the for profit company mentioned) has the only commercial implementation/adjacent software is a problem, yes. But "snake oil" doesn't quite match up with the fact that SCION right now provides the backbone for the Swiss financial network moving 200 billion CHF each day [1], so at least some level of workable technology has to be there. And for no one to be taking it seriously, there's a decently long list of multinational ISPs at the very least taking steps towards offering SCION to customers [2] (e.g. British Telecom has expressed enough interest that they have various recent marketing videos on Anapaya's YouTube channel). Finally, I'm not sure what you mean regarding the "scummy inclusion of block chain / crypto" - as someone who has worked on SCION-based projects I never heard anything about this. Apparently a blockchain company invested in Anapaya, but that doesn't really change anything about the protocol itself, does it?
Because SCION is mostly said as a joke in the more serious carrier world.
SCION is practically speaking proprietary, and has 1 and maybe a half implementations. I have a laundry list of real problems with SCION but SCION feels like one of those entities that would get quite legal-ey if discussed publicly.
> I have a laundry list of real problems with SCION but SCION feels like one of those entities that would get quite legal-ey if discussed publicly.
How laughable. This looks more like you are afraid of embarrassing yourself in public. Publish your list or shut up. Also, there is nothing stopping you from mailing the respective researchers in private.
Then again, it's April 1st, so I'm not sure whether I should take you seriously.
This actually shows pretty good coverage for this feature, it seems to me. The big American isps do it, the mobile ones do too...
How many major isps would we want to implement it to be "safe" and what would that look like? Is this a regional thing? They've only listed 4 unsafe ones on the site and that doesn't seem like a major issue, but maybe they're very large somewhere.
I'm on sky in the UK which is marked as not safe due to no RPKI.
It's not on the list so imagine there is a fair few missing, would be neat to have a table you could filter by country, provider type (cloud/isp etc) based on real results from users.
edit: there's a show all button to expand the table
My hope would be that A&A have a process manually whitelisting the route that made the test fail because in fact (as of course it would be) it's actually deliberately not signed but it is really their route.
But on some level that's like assuming the reason the guy with the handgun is on your plane is that he's a sky marshal and not that some idiot let a concealed handgun through security. I mean, sure, maybe, but, maybe not.
Without asking it's just a guess and I haven't asked. Maybe I should.
T-Mobile consists of at least five distinct networks depending on when your carrier was purchased, last time I was talking with some of the network security guys in Factoria. It’s been four years - they may have converged some of them.
Major ISPs like British Telecom (core UK telephony), NTT Docomo (Japan), Vodafone Espana (showing that Vodafone isn't doing it globally), Starlink (showing it's not a old tech problem), Rogers (US ISP) are listed unsafe.
I think the 31 is a misleadingly positive picture.
> A BGP hijack occurs when a malicious node deceives another node, lying about what the routes are for its neighbors. Without any security protocols, this misinformation can propagate from node to node, until a large number of nodes now know about, and attempt to use these incorrect, nonexistent, or malicious routes.
But with HTTPS, they wouldn't be able to actually pose as another website, just delay/black hole the request so it doesn't reach its goal target, right? From the figure, it makes it seem like a person can use BGP to spoof a website and make a user visit a phished website, but that's not right, correct?
BGP attacks have nothing to do with spoofed peers. They have to do with accepted peers behaving maliciously in terms of the AS Paths they advertise.
Once you control BGP you control any IP and can subvert certificate issuance that effectively uses IP to validate certificate issuance requests. For example anything that relies on a file or dns at a specific IP. Once you have done so, you ARE the site, no matter what HSTS says.
We’ve tried to solve this problem a few times with certificate pinning (dangerous) and more recently just giving up and using certificate transparency to try and mitigate the blast radius by hoping the duration can be curtailed. The whole system is incredibly fragile.
As an aside, BGP should move over to TLS (not https, http is a terrible protocol for this) for other reasons (it’s a better option than tcp aom/md5). That this is not already the case should inform people’s opinion of where this stuff is on the security timeline.
You just need to get a publicly trusted CA to mint a certificate for your new site.
This can be done, for example, with let’s encrypt, using several of the various domain verification challenges they support.
There are some protections against this, such as CAA records in DNS, which restrict which CAs can issue certs and depending on the CA which verification methods are allowed. That may not provide adequate protection.
For example if you are using LE and are using verification mechanisms other than DNS then the attacker could trick LE to issuing it a cert.
That also depends on the security of DNS, which can be tricky.
So, yes, BGP hijacks can be used to impersonate other sites, even though they are using HTTPS.
When you configure your domains,
Make sure you setup CAA, locked down to your specific CA, and have DNS sec setup, as a minimum bar. Also avoid using DV mechanisms that only rely on control over an IP address, as that can be subverted via BGP.
Well if they can deceive certificate authorities that implement the ACME protocol like LetsEncrypt, then they could get a certificate for your site with the HTTP-01 challenge, see the paper Using BGP to Acquire Bogus TLS Certificates (2017) [1]. That paper suggested a mitigation they call Multiple Vantage Point Verification, which has already been implemented [2].
They don't need ACME to do that, ACME is just an automation standard - the same rules apply for getting a certificate via ACME such as 3.2.2.4.19 "Agreed upon change to website - ACME" as for the manual process 3.2.2.4.18 "Agreed upon change to website v2". The ACME version is just designed for machines to automate easily (and as a result wildly more common in use today)
And Multi-perspective only helps against an attacker who is merely able to influence a local route, if they can ensure all your perspectives see the same thing the attacker wins.
For anything major you're right, you'd expect them to be on the HSTS preload list in people's browsers which forces all requests over SSL which would then pick up an invalid certificate. That doesn't make this harmless though, just being able to blackhole traffic for something is a pretty significant attack - Pakistan a few years back accidentally caused YouTube to be unavailable ~worldwide when they only intended to make it unavailable within the country. There's also a lot of sites not on the preload list, and those you could fairly easily MITM, especially if you've also got access to a tame certificate issuer and I don't doubt that a nation state could persuade someone to issue them some certificates given the proper levers.
RPKI doesn't make BGP safe, it makes it safer. BGP hijacks can still happen.
RPKI only secures the ownership information of a given prefix, not the path to that prefix. Under RPKI, an attacker can still claim to be on the path to a victim AS, and get the victim's traffic sent to it.
The solution to this was supposed to be BGPSec, but it's widely seen as un-deployable.
> and get the victim's traffic sent to it
This sounds "obviously bad" but the intricacies of routing aren't really my field, could you expand on why this is bad? (i.e. what specific bad things does it enable)
I believe the current attempt at mitigation for this is ASPA[0]. It still has a long way to go, but there are some big names behind it.
[0]: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-asp...
I think the test for BGP is Safe is when we stop using it and instead use SCION: https://en.wikipedia.org/wiki/SCION_(Internet_architecture).
SCION is generally considered snake oil within the network operator community. Its weird single vendor for profit company that ships it's software, the fact that no router hw asic fwding supports what they want to do and then the general scummy inclusion of block chain / crypto as well as some "green washing" for PR hype.
Sure the swiss have their toy but no one is taking it seriously.
Hmm, I'd disagree. The fact that Anapaya Systems (the for profit company mentioned) has the only commercial implementation/adjacent software is a problem, yes. But "snake oil" doesn't quite match up with the fact that SCION right now provides the backbone for the Swiss financial network moving 200 billion CHF each day [1], so at least some level of workable technology has to be there. And for no one to be taking it seriously, there's a decently long list of multinational ISPs at the very least taking steps towards offering SCION to customers [2] (e.g. British Telecom has expressed enough interest that they have various recent marketing videos on Anapaya's YouTube channel). Finally, I'm not sure what you mean regarding the "scummy inclusion of block chain / crypto" - as someone who has worked on SCION-based projects I never heard anything about this. Apparently a blockchain company invested in Anapaya, but that doesn't really change anything about the protocol itself, does it?
[1] https://www.scion.org/ssfn-scion/ [2] https://www.scion.org/isps/
Why hasn't this happened?
Because SCION is mostly said as a joke in the more serious carrier world.
SCION is practically speaking proprietary, and has 1 and maybe a half implementations. I have a laundry list of real problems with SCION but SCION feels like one of those entities that would get quite legal-ey if discussed publicly.
> I have a laundry list of real problems with SCION but SCION feels like one of those entities that would get quite legal-ey if discussed publicly.
How laughable. This looks more like you are afraid of embarrassing yourself in public. Publish your list or shut up. Also, there is nothing stopping you from mailing the respective researchers in private.
Then again, it's April 1st, so I'm not sure whether I should take you seriously.
Because BGP works, is understood, and has been debugged by thousands of people and billions of sessions between dozens or hundreds of implementations.
So the benefit of changing out all that infrastucture needs to be much higher than the cost.
This actually shows pretty good coverage for this feature, it seems to me. The big American isps do it, the mobile ones do too...
How many major isps would we want to implement it to be "safe" and what would that look like? Is this a regional thing? They've only listed 4 unsafe ones on the site and that doesn't seem like a major issue, but maybe they're very large somewhere.
I'm on sky in the UK which is marked as not safe due to no RPKI.
It's not on the list so imagine there is a fair few missing, would be neat to have a table you could filter by country, provider type (cloud/isp etc) based on real results from users.
edit: there's a show all button to expand the table
If you're interested, Community Fibre is a yes from this website
I get the same result for A&A, but frankly I trust them more than some random site with (apparently) an axe to grind.
https://www.aa.net.uk/etc/news/bgp-and-rpki/
My hope would be that A&A have a process manually whitelisting the route that made the test fail because in fact (as of course it would be) it's actually deliberately not signed but it is really their route.
But on some level that's like assuming the reason the guy with the handgun is on your plane is that he's a sky marshal and not that some idiot let a concealed handgun through security. I mean, sure, maybe, but, maybe not.
Without asking it's just a guess and I haven't asked. Maybe I should.
I got a fail on T-Mobile USA. It seems in the full list that T-Mobile is listed as both passing and failing.
T-Mobile consists of at least five distinct networks depending on when your carrier was purchased, last time I was talking with some of the network security guys in Factoria. It’s been four years - they may have converged some of them.
same
We want more than just major isps.
They've listed way more than 4 (and those 4 are also massive), click "Show all".
There's 254 operators marked as unsafe.
Click show all.
Major ISPs like British Telecom (core UK telephony), NTT Docomo (Japan), Vodafone Espana (showing that Vodafone isn't doing it globally), Starlink (showing it's not a old tech problem), Rogers (US ISP) are listed unsafe.
I think the 31 is a misleadingly positive picture.
I thought Rogers was Canadian.
rpki adoption is the new ipv6 adoption. it looks great until you realize it only validates who owns the prefix, not the path to get there lol
Any reasons on why an ISP would not implement it other than effort/cost? Just for someone like me whose networks knowledge is very naive.
An ISP is marked as unsafe in the table, yet running the test says it is. (same ASN)
the last update on the table was feb 3. presumably rpki was implemented between then and now
ISP's often have different infrastructure for different sets of customers (regional, mobile/landline differences etc) - often due to legacy M&As etc..
Looks like Verizon does it correctly.
> Your ISP (Verizon, AS701) implements BGP safely. It correctly drops invalid prefixes.
Google And digital ocean are huge players here but is there a reason they would only have partial coverage?
TIM is listed as insecure yet my test is successful.
> Your ISP (Telecom Italia S.p.a., AS3269) implements BGP safely. It correctly drops invalid prefixes
Google being shown as unsafe makes me think they have some internal methods for filtering?
> A BGP hijack occurs when a malicious node deceives another node, lying about what the routes are for its neighbors. Without any security protocols, this misinformation can propagate from node to node, until a large number of nodes now know about, and attempt to use these incorrect, nonexistent, or malicious routes.
But with HTTPS, they wouldn't be able to actually pose as another website, just delay/black hole the request so it doesn't reach its goal target, right? From the figure, it makes it seem like a person can use BGP to spoof a website and make a user visit a phished website, but that's not right, correct?
BGP attacks have nothing to do with spoofed peers. They have to do with accepted peers behaving maliciously in terms of the AS Paths they advertise.
Once you control BGP you control any IP and can subvert certificate issuance that effectively uses IP to validate certificate issuance requests. For example anything that relies on a file or dns at a specific IP. Once you have done so, you ARE the site, no matter what HSTS says.
We’ve tried to solve this problem a few times with certificate pinning (dangerous) and more recently just giving up and using certificate transparency to try and mitigate the blast radius by hoping the duration can be curtailed. The whole system is incredibly fragile.
As an aside, BGP should move over to TLS (not https, http is a terrible protocol for this) for other reasons (it’s a better option than tcp aom/md5). That this is not already the case should inform people’s opinion of where this stuff is on the security timeline.
You can use BGP hijacks to spoof another website.
You just need to get a publicly trusted CA to mint a certificate for your new site.
This can be done, for example, with let’s encrypt, using several of the various domain verification challenges they support.
There are some protections against this, such as CAA records in DNS, which restrict which CAs can issue certs and depending on the CA which verification methods are allowed. That may not provide adequate protection.
For example if you are using LE and are using verification mechanisms other than DNS then the attacker could trick LE to issuing it a cert.
That also depends on the security of DNS, which can be tricky.
So, yes, BGP hijacks can be used to impersonate other sites, even though they are using HTTPS.
When you configure your domains, Make sure you setup CAA, locked down to your specific CA, and have DNS sec setup, as a minimum bar. Also avoid using DV mechanisms that only rely on control over an IP address, as that can be subverted via BGP.
Well if they can deceive certificate authorities that implement the ACME protocol like LetsEncrypt, then they could get a certificate for your site with the HTTP-01 challenge, see the paper Using BGP to Acquire Bogus TLS Certificates (2017) [1]. That paper suggested a mitigation they call Multiple Vantage Point Verification, which has already been implemented [2].
[1]: https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.p...
[2]: https://community.letsencrypt.org/t/validating-challenges-fr...
They don't need ACME to do that, ACME is just an automation standard - the same rules apply for getting a certificate via ACME such as 3.2.2.4.19 "Agreed upon change to website - ACME" as for the manual process 3.2.2.4.18 "Agreed upon change to website v2". The ACME version is just designed for machines to automate easily (and as a result wildly more common in use today)
And Multi-perspective only helps against an attacker who is merely able to influence a local route, if they can ensure all your perspectives see the same thing the attacker wins.
For anything major you're right, you'd expect them to be on the HSTS preload list in people's browsers which forces all requests over SSL which would then pick up an invalid certificate. That doesn't make this harmless though, just being able to blackhole traffic for something is a pretty significant attack - Pakistan a few years back accidentally caused YouTube to be unavailable ~worldwide when they only intended to make it unavailable within the country. There's also a lot of sites not on the preload list, and those you could fairly easily MITM, especially if you've also got access to a tame certificate issuer and I don't doubt that a nation state could persuade someone to issue them some certificates given the proper levers.
If you can inject arbitrary malicious routes, you can make ACME requests for a new cert.