Is BGP safe yet?
isbgpsafeyet.com
isbgpsafeyet.com
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.
https://rot256.dev/post/bgp-pcd/
Proof-carrying data has come a long way in the last 10 years.
EDIT: you would still need RPKI, but not BGPSec
[0]: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-asp...
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)
The attacker can impersonate the victim, get a valid x509 certificate issued to it, and create a perfect replica of their website/api/whatever.
The attacker can perform a man-in-the-middle attack on the victim - record traffic, inject traffic, manipulate traffic, etc.
The attacker can just deny access to the victim - just drop packets meant for the victim.
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.
It would be "enough" if all the major transit ISPs did it and it would be helpful if all the major residential ISPs did it. If non-RPKI routes can't propagate through transit ISPs, that makes it a much less useful thing to do.
They've listed way more than 4 (and those 4 are also massive), click "Show all".
There's 254 operators marked as unsafe.
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
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.
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.
Not sure if it makes a difference, but I had a T-Mobile SIM card I bought in Seattle in 2010 and was carrying from phone to phone for years, but I recently replaced the SIM because I heard newer t-mobile SIMs can do better finding 5g coverage.
T-Mobile USA, AS21928 does NOT implement BGP safely Free SAS ISP signed unsafe
Your ISP (Free SAS, AS12322) implements BGP safely. It correctly drops invalid prefixes. Tweet this → Details fetch https://valid.rpki.isbgpsafeyet.com correctly accepted valid prefixes
fetch https://invalid.rpki.isbgpsafeyet.com correctly rejected invalid prefixes
Sure the swiss have their toy but no one is taking it seriously.
[1] https://www.scion.org/ssfn-scion/ [2] https://www.scion.org/isps/
As for BT - they're just one broadband ISP operating primarily in a single country. I don't see that moving the needle - you're missing CDNs, traditional large scale "tier 1s" and cloud or large hosting networks.
RPKI got to where it is today through community engagement by folks like Job S. and others - hitting the conferences, direct engagement with operators and raising the bar from a software quality and standards perspective - which still continues today. That's how you get the internet to adopt something that is considered the new normal.
As for your ISP list - I know there are networks listed there that aren't running scion in a production capacity (perhaps you can run scion in a virtualized environment on top of them which is different than those companies running it on their production network).
As for the block chain - it was all the Sui stuff.
This is a meaningless benchmark - for a small group of trusted big enterprises with insurance policies and mutually signed contracts you could've just as well used OSPF with zero filters.
The benchmark would be adoption by an actual large number of parties that don't/can't talk to eachother spread across the world. With a large chunk of them being malicious or incompetent to the point of being effectively malicious.
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.
So the benefit of changing out all that infrastucture needs to be much higher than the cost.
However, it'd be equally irresponsible to ask for an innovation budget of 0 percent. The reason one bothers with new approaches is, of course, that fixing things on a conceptual level prevents many of the debugging sessions that you had to go through with the old approach. Why QUIC if there is TCP/TLS/HTTP?
IPv4 and NAT are literally _everywhere_. It's tested and well-understood (one would think). But—and that's just my opinion—I sure hope that, one day, we will not have to deal with that mess no more ...
I guess the attack could still be used for denial of service.
> the attacker issued and registered a free temporary 3-month certificate for the developers[.]kakao.com domain through SSL certificate issuer called ZeroSSL. Because the routing policy was already manipulated by the BGP Hijacking, the attacker was able to register the certificate.
https://medium.com/s2wblog/post-mortem-of-klayswap-incident-...
Currently there are no good monitors though aka the system is a bit broken.
> Your ISP (Verizon, AS701) implements BGP safely. It correctly drops invalid prefixes.
We're all internetworking at the pleasure of IANA. Getting them out of the picture, and removing their ability to deplatform Internet participants, is a much larger task than just moving away from RPKI. We'd need to completely rethink how ASN and IP assignments are done.
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
They may have older hardware that needs to be upgraded before they can use this feature.
They might even have their own way of filtering that they think is good enough.
Though, all of those really boil down to effort/cost.
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?
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.
Dangerous how? Create a CAA record which pins your CA and only allow dns01 challenge. Problem solved, a BGP hijack can't issue a valid certificate for your site.
[1]: https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.p...
[2]: https://community.letsencrypt.org/t/validating-challenges-fr...
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.
Yes this is why multi-perspective is described as a "mitigation" above. Ideally, ACME issuers have a large array of perspectives with additional perspectives added frequently to foil planned attacks. But real BGP security is the actual solution to this problem.
This document is essentially an agreement between the Trust Stores (largely the browser vendors such as Microsoft, Google, Apple, and Mozilla) on behalf of their Relying Parties (everybody) and the Certificate Authorities they choose to trust. It lays out the requirements on what the CAs may do and how they may do it, the numbers I quoted were sub-section numbers for what are sometimes called the "Blessed Methods" which these days are listed in those requirements - for how a CA shall check that say a certificate for news.ycombinator.com can be issued to this web server we're both using.
This isn't a "standard" really, any more than you'd say the Geneva Conventions were standards. It specifies (that "- ACME" is from the document, it's not my addition) that you can use some ACME protocol features to achieve the name confirming requirement but it also specifies some ways to do so manually. Last month quite a few of the older methods were finally stopped for new issuance (though existing confirmations for those methods will keep working for a few years if you have them). Stuff like "Find the landline phone number for the company in a government directory and call them" which I'm not sure really still made sense when the BRs were first agreed, let alone last month when it was finally removed.
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.
Major news outlets, government websites from various countries, the American army, and many more all lack CAA records, for instance. Any CA can generate a valid certificate for those domains and it's up to the people watching the public certificate transparency logs to catch any malicious certificates.