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

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.

Sure the swiss have their toy but no one is taking it seriously.

[1]: https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.p...

[2]: https://community.letsencrypt.org/t/validating-challenges-fr...

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.

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

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