alt.hn

4/1/2026 at 1:10:29 PM

Is BGP safe yet?

 https://isbgpsafeyet.com/

by janandonly

4/1/2026 at 2:06:14 PM

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.

by maltalex

4/1/2026 at 3:06:11 PM

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

by rot256

4/1/2026 at 2:29:19 PM

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...

by impl

4/1/2026 at 3:25:21 PM

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.

by greyface-

4/1/2026 at 3:51:15 PM

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.

by heyethan

4/1/2026 at 6:58:44 PM

“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.

by altairprime

4/1/2026 at 3:16:09 PM

[dead]

by diablevv

4/1/2026 at 6:20:21 PM

I think RPKI is good enough. As we have TLS on top it doesn't need to be perfect.

by hugo1789

4/1/2026 at 7:07:32 PM

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.

by rot256

4/1/2026 at 11:49:13 PM

DNSSEC and DNS-01 challenges might do the trick at the cost of significant effort, provided LE could be directed to check, similar to the way MTA-STS works.

by gerdesj

4/2/2026 at 3:24:38 AM

Let’s Encrypt has been doing DNSSEC validation for years. DNSSEC could have prevented the jabber.ru MITM attack.

by fanf2

4/1/2026 at 6:35:36 PM

Only with certificate pinning or something similar. Otherwise, the attacker can get valid TLS certificates for any domain hosted on the hijacked IP addresses.

by maltalex

4/1/2026 at 8:16:14 PM

Those two things address orthogonal issues

by zymhan

4/1/2026 at 2:57:24 PM

> 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)

by Retr0id

4/1/2026 at 3:17:02 PM

Here are some examples:

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.

by maltalex

4/2/2026 at 7:35:30 AM

RPKI and ASPA keeps you safer from other networks, but less safe from the registries. Consider what happens if your registry's country sanctions your country and you are unable to update any records held at the registry.

by pocksuppet

4/1/2026 at 1:32:14 PM

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.

by nemomarx

4/1/2026 at 5:10:38 PM

> 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.

by toast0

4/1/2026 at 1:38:36 PM

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.

by KomoD

4/1/2026 at 1:40:14 PM

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

by chrismustcode

4/1/2026 at 2:14:00 PM

If you're interested, Community Fibre is a yes from this website

by SCdF

4/1/2026 at 1:55:02 PM

I get the same result for A&A, but frankly I trust them more than some random site with (apparently) an axe to grind.

by badgersnake

4/1/2026 at 2:26:06 PM

https://www.aa.net.uk/etc/news/bgp-and-rpki/

by jsty

4/1/2026 at 4:26:22 PM

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.

by OJFord

4/1/2026 at 2:24:59 PM

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.

by tialaramex

4/1/2026 at 3:45:30 PM

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.

by tialaramex

4/1/2026 at 2:41:30 PM

I got a fail on T-Mobile USA. It seems in the full list that T-Mobile is listed as both passing and failing.

by asveikau

4/1/2026 at 2:50:07 PM

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.

by RyJones

4/1/2026 at 6:09:12 PM

Also failing here in the Los Angeles area. Used to be on Sprint before the acquisition. Probably location dependent

by Melatonic

4/1/2026 at 8:28:19 PM

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.

by asveikau

4/1/2026 at 3:01:24 PM

same

     T-Mobile USA, AS21928 does NOT implement BGP safely

by ck2

4/1/2026 at 1:42:32 PM

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.

by philipwhiuk

4/1/2026 at 2:42:20 PM

I thought Rogers was Canadian.

by asveikau

4/1/2026 at 4:09:06 PM

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.

by hrmtst93837

4/1/2026 at 8:32:13 PM

Ironic this is from Cloudfare, probably the single entity most likely to be responsible for breaking the internet in 2026

by ifwinterco

4/2/2026 at 7:36:13 AM

That's just how entrepreneurship is done these days. You aim to mislead the public in ways that benefit you, and somehow it actually works. If RPKI benefits you, you roll out a campaign that RPKI is great and necessary for internet safety. If you want to know all your users' real names, you roll out a campaign that age verification via identity document is needed to keep children safe on the internet. If your company sells separate measles, mumps and rubella vaccines, you roll out a campaign that the combined MMR vaccine makes children autistic. If your company sells weapons, you roll out a campaign to subsidize movies and video games that portray war as awesome and manly. If your company sells cigarettes but only men are buying them, you roll out a campaign that sells the freedom to smoke as a benefit of feminism. All of these things actually happened.

by pocksuppet

4/1/2026 at 3:19:47 PM

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?

by greyface-

4/1/2026 at 3:53:04 PM

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

by dorianmariecom

4/1/2026 at 8:18:08 PM

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.

by surround

4/1/2026 at 8:22:05 PM

Once you have control of the destination, you could get a valid SSL certificate with Letsencrypt or whatever.

by icedchai

4/1/2026 at 10:10:04 PM

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-...

by surround

4/1/2026 at 11:49:01 PM

You could mitigate this by monitoring certificate transparency logs for unwanted certificates issued for your domain.

Currently there are no good monitors though aka the system is a bit broken.

by sureglymop

4/1/2026 at 1:52:43 PM

An ISP is marked as unsafe in the table, yet running the test says it is. (same ASN)

by olivier5199

4/1/2026 at 1:57:15 PM

the last update on the table was feb 3. presumably rpki was implemented between then and now

by john_strinlai

4/1/2026 at 2:34:43 PM

ISP's often have different infrastructure for different sets of customers (regional, mobile/landline differences etc) - often due to legacy M&As etc..

by arnorhs

4/1/2026 at 1:44:07 PM

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).

by commandersaki

4/1/2026 at 2:12:07 PM

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.

by pigggg

4/1/2026 at 2:54:56 PM

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/

by xyquadrat

4/1/2026 at 4:06:33 PM

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.

by pigggg

4/1/2026 at 6:05:34 PM

IIRC, UBS used to use IRC (yes, that IRC) as a messaging "backbone", so I'm not sure this really counts as a POC.

by tptacek

4/1/2026 at 3:25:14 PM

200billion CHF....how big is that in bandwidth?

by tonetegeatinst

4/1/2026 at 3:47:29 PM

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/

by bo0tzz

4/1/2026 at 5:36:45 PM

So ... nothing. At least in comparison.

by BadBadJellyBean

4/1/2026 at 4:46:12 PM

> 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.

by q3k

4/1/2026 at 6:28:18 PM

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.

by xyquadrat

4/1/2026 at 11:58:17 PM

I gotta say some of the proposed use cases are things no one is looking/asking for. One I recall was having a network decide to reach another network by avoiding countries that aren't carbon neutral (which could take longer hops and use more infra / more energy...) feels like they're trying to say they're the green/environmental friendly protocol.

by pigggg

4/1/2026 at 10:25:26 PM

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.

by raron

4/1/2026 at 10:13:16 PM

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?

by q3k

4/1/2026 at 2:04:26 PM

Why hasn't this happened?

by wussboy

4/1/2026 at 2:08:36 PM

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.

by benjojo12

4/1/2026 at 2:45:10 PM

[flagged]

by genuineDSD

4/1/2026 at 2:08:38 PM

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.

by dsr_

4/1/2026 at 3:19:52 PM

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.

by lucasay

4/1/2026 at 2:46:49 PM

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

by kevincloudsec

4/1/2026 at 2:17:33 PM

Looks like Verizon does it correctly.

> Your ISP (Verizon, AS701) implements BGP safely. It correctly drops invalid prefixes.

by collabs

4/1/2026 at 1:40:17 PM

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

by bilekas

4/1/2026 at 2:20:19 PM

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.

by elashri

4/1/2026 at 3:43:18 PM

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.

by dec0dedab0de

4/1/2026 at 3:41:05 PM

When was the last time this site was updated? It mentions Sprint, which hasn't existed for years.

by NetOpWibby

4/1/2026 at 3:45:01 PM

I think it just goes by ASN. Looks like Comcast owns the Sprint ASN now.

by dec0dedab0de

4/1/2026 at 1:39:43 PM

Google being shown as unsafe makes me think they have some internal methods for filtering?

by RRRA

4/1/2026 at 2:01:37 PM

> 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?

by NewsaHackO

4/1/2026 at 2:16:58 PM

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.

by foobiekr

4/1/2026 at 2:11:58 PM

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...

by infogulch

4/1/2026 at 2:39:20 PM

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.

by tialaramex

4/1/2026 at 5:09:06 PM

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.

by infogulch

4/1/2026 at 5:35:11 PM

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.

by tialaramex

4/1/2026 at 2:36:58 PM

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.

by swisniewski

4/1/2026 at 2:16:06 PM

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.

by jon-wood

4/1/2026 at 3:13:31 PM

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.

by jeroenhd

4/1/2026 at 2:11:48 PM

If you can inject arbitrary malicious routes, you can make ACME requests for a new cert.

by dsr_

4/1/2026 at 3:37:23 PM

Wikimedia is an ISP?

by volemo

4/1/2026 at 3:38:21 PM

When they say ISP they mean anything with an ASN

by dec0dedab0de

4/1/2026 at 1:37:20 PM

[dead]

by nareyko