[HN Gopher] Is BGP safe yet?
___________________________________________________________________
Is BGP safe yet?
Author : janandonly
Score : 229 points
Date : 2026-04-01 13:10 UTC (9 hours ago)
(HTM) web link (isbgpsafeyet.com)
(TXT) w3m dump (isbgpsafeyet.com)
| nemomarx wrote:
| 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.
| KomoD wrote:
| 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.
| chrismustcode wrote:
| 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
| badgersnake wrote:
| I get the same result for A&A, but frankly I trust them more
| than some random site with (apparently) an axe to grind.
| tialaramex wrote:
| 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.
| tialaramex wrote:
| And now thanks to jsty's sibling comment I don't have to
| ask, thanks! It does seem like they've been more than
| "cautious" enough at this point and should just implement
| RPKI.
| jsty wrote:
| https://www.aa.net.uk/etc/news/bgp-and-rpki/
| OJFord wrote:
| And here we are six years on... I have a lot of respect
| for A&A, but I do find it hard to sympathise with that
| page.
| SCdF wrote:
| If you're interested, Community Fibre is a yes from this
| website
| philipwhiuk wrote:
| 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.
| asveikau wrote:
| I thought Rogers was Canadian.
| hrmtst93837 wrote:
| Counting networks passes for journalism, and 31 is noise
| unless you weight each entry by size and traffic split. A
| pile of single-homed stubs matters far less than one big
| transit network, because outages and hijacks bite where
| traffic concentrates, and that makes the headline number feel
| brokn rather than reassuring.
| asveikau wrote:
| I got a fail on T-Mobile USA. It seems in the full list that
| T-Mobile is listed as both passing and failing.
| RyJones wrote:
| 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.
| Melatonic wrote:
| Also failing here in the Los Angeles area. Used to be on
| Sprint before the acquisition. Probably location dependent
| asveikau wrote:
| I got the failure message in San Francisco.
|
| 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.
| ck2 wrote:
| same T-Mobile USA, AS21928 does NOT
| implement BGP safely
| toast0 wrote:
| > How many major isps would we want to implement it to be
| "safe" and what would that look like?
|
| 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.
| RRRA wrote:
| Google being shown as unsafe makes me think they have some
| internal methods for filtering?
| bilekas wrote:
| 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
| commandersaki wrote:
| 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).
| wussboy wrote:
| Why hasn't this happened?
| benjojo12 wrote:
| 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.
| dsr_ wrote:
| 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.
| pigggg wrote:
| 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.
| xyquadrat wrote:
| 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/
| tonetegeatinst wrote:
| 200billion CHF....how big is that in bandwidth?
| bo0tzz wrote:
| 2.6 million transactions per day [0], which in ISO 20022
| XML format messages works out to (rough guess) 20GB per
| day for an average of 1.8Mbps...
|
| [0]: https://www.scion.org/ssfn-scion/
| BadBadJellyBean wrote:
| So ... nothing. At least in comparison.
| pigggg wrote:
| I don't think the swiss banking network is really the right
| thing to point to. Folks measure networks in bps/pps, not
| financial transactions - nevermind the actual control plane
| bits (num of prefixes, as paths, etc.). Plus it's all
| within one country where you have the luxury of being able
| to directly influence and steer those companies into
| adopting this.
|
| 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.
| q3k wrote:
| > SCION right now provides the backbone for the Swiss
| financial network moving 200 billion CHF each day
|
| 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.
| xyquadrat wrote:
| I'm not claiming that this shows SCION can replace the
| respective parts of the network stack right now, and
| you're right that at a global scale this is still an
| unproven technology. But I would argue that a technology
| needs a certain level of matureness / is not "snake oil"
| if it is deployed in a heavily regulated and
| comparatively conservative sector such as banking.
| q3k wrote:
| Aren't heavily regulated sectors the one where you
| usually encounter snake oil? Useless WAFs and other
| security snake oil products, Microsoft 'collaboration'
| jank like Teams and Sharepoint, MitM proxies, etc?
| raron wrote:
| Why does a routing protocol matter for the banking
| sector? With proper encryption the route the packets of
| transaction data takes should not matter at all.
| tptacek wrote:
| IIRC, UBS used to use IRC (yes, that IRC) as a messaging
| "backbone", so I'm not sure this really counts as a POC.
| olivier5199 wrote:
| An ISP is marked as unsafe in the table, yet running the test
| says it is. (same ASN)
| john_strinlai wrote:
| the last update on the table was feb 3. presumably rpki was
| implemented between then and now
| arnorhs wrote:
| ISP's often have different infrastructure for different sets
| of customers (regional, mobile/landline differences etc) -
| often due to legacy M&As etc..
| NewsaHackO wrote:
| > 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?
| dsr_ wrote:
| If you can inject arbitrary malicious routes, you can make ACME
| requests for a new cert.
| ThomasGlanzmann wrote:
| You can mitigate this with DNSSEC, CAA records and account
| pinning. See: https://www.devever.net/~hl/xmpp-incident
| infogulch wrote:
| 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...
| tialaramex wrote:
| 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.
| infogulch wrote:
| So there is a more general standard which the ACME protocol
| automates. Or perhaps another way to put it is that, the
| standard is written in a way that "just happens" to be
| nicely automatable.
|
| 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.
| tialaramex wrote:
| Not exactly. There's a document, the Baseline
| Requirements or BRs: https://cabforum.org/working-
| groups/server/baseline-requirem...
|
| 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.
| jon-wood wrote:
| 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.
| jeroenhd wrote:
| Only as long as all certificate authorities ensure that all
| networks they host servers on secure. If you can BGP spoof a
| domain-validating CA, you can get a valid certificate for any
| domain of your choice (unless maybe if that domain is DNSSEC-
| enabled, the CA does strict validation, and the domain has a
| CAA record for another CA that is not BGP-spoofable).
|
| 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.
| foobiekr wrote:
| 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.
| swisniewski wrote:
| 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.
| maltalex wrote:
| 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.
| impl wrote:
| 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...
| greyface- wrote:
| It has a long way to go, in the same sense that ROA had a
| long way to go when Cloudflare first launched this site in
| 2020. ASPA records are fully supported by both RIPE and ARIN
| these days.
| Retr0id wrote:
| > 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)
| rot256 wrote:
| I think that way to solve BGPs security problems might be to
| use a new cryptographic hammer, "Proof-Carraying Data", where
| messages come with cryptographic proofs that they were produced
| correctly. This allows you to basically just run BGP, but every
| AS proves that it ran it correctly. The proofs take constant
| time to verify, regardless of how large the network is, or how
| many hops the routing message has taken. Feasibility is helped
| by latency not being super critical in BGP and BGP being a
| pretty simple protocol; which makes computing these proofs
| plausible.
|
| 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
| heyethan wrote:
| RPKI makes prefix ownership verifiable, but the path is still
| largely trust-based.
|
| It feels like we've secured the part that's easiest to
| validate, not necessarily the part that matters most.
| hugo1789 wrote:
| I think RPKI is good enough. As we have TLS on top it doesn't
| need to be perfect.
| maltalex wrote:
| Only with certificate pinning or something similar.
| Otherwise, the attacker can get valid TLS certificates for
| any domain hosted on the hijacked IP addresses.
| rot256 wrote:
| For LetsEncrypt, routing _is_ authentication: if packets
| routed to the IP in the A record end up at your place, you
| can get a cert for that domain.
| zymhan wrote:
| Those two things address orthogonal issues
| altairprime wrote:
| "Safe" the platonic ideal is an impossibility. Any
| cryptographic solution depends ultimately on handshake
| agreements between fallible human executives and/or fallible
| human registries, and there's no known alternative to that
| today. Is RPKI "safe", relative to not RPKI? Yes, obviously, it
| is. Is it reasonable to interpret "safe" as 'no further
| improvement is required'? Never: this is the Internet; one
| could expect the domain to be repurposed to cover more than
| RPKI someday. Yes, short-sighted leaders may use "RPKI is safe"
| as justification to withhold investment forward past it; but
| that outcome is certain regardless of _how_ they justify it.
| collabs wrote:
| Looks like Verizon does it correctly.
|
| > Your ISP (Verizon, AS701) implements BGP safely. It correctly
| drops invalid prefixes.
| elashri wrote:
| 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.
| dec0dedab0de wrote:
| They may be worried that their larger clients don't have things
| configured correctly, and they don't want to break things for
| them.
|
| 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.
| kevincloudsec wrote:
| 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
| betaby wrote:
| Path validation is handled by ASPA https://www.ripe.net/manage-
| ips-and-asns/resource-management...
| greyface- wrote:
| RPKI isn't just ROAs anymore, and BGP hijacks can happen at other
| places than just the first/last hop. Why hasn't this site been
| updated to test ASPA-invalid prefixes in addition to ROA-invalid
| ones?
| lucasay wrote:
| RPKI makes BGP safer, not safe. It helps prevent some hijacks,
| but attackers can still mess with routing paths. Feels like we're
| patching a trust-based system rather than fixing it.
| volemo wrote:
| Wikimedia is an ISP?
| dec0dedab0de wrote:
| When they say ISP they mean anything with an ASN
| NetOpWibby wrote:
| When was the last time this site was updated? It mentions Sprint,
| which hasn't existed for years.
| dec0dedab0de wrote:
| I think it just goes by ASN. Looks like Comcast owns the Sprint
| ASN now.
| dorianmariecom wrote:
| i'm getting: Free SAS ISP signed unsafe
|
| but when testing i'm getting a success
|
| 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
| Levitating wrote:
| Does not take BGPSec[1] into account, just RPKI.
|
| [1]: https://en.wikipedia.org/wiki/BGPsec
| surround wrote:
| The graphic that shows that a hijacker can route traffic to their
| malicious website is a little misleading. Since the SSL
| certificate would be invalid, browsers would block the connection
| and show a warning.
|
| I guess the attack could still be used for denial of service.
| icedchai wrote:
| Once you have control of the destination, you could get a valid
| SSL certificate with Letsencrypt or whatever.
| surround wrote:
| Wow I'm surprised, you're right, and it has happened before:
|
| > 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-...
| ifwinterco wrote:
| Ironic this is from Cloudfare, probably the single entity most
| likely to be responsible for breaking the internet in 2026
___________________________________________________________________
(page generated 2026-04-01 23:00 UTC)