Just wanted to summarize the challenges faced by today’s web browser. The only way to survive a BGP hijack intact is also a deal breaker for today’s typical co

Just wanted to summarize the challenges faced by today’s web browser. The only way to survive a BGP hijack intact is also a deal breaker for today’s typical common web browser. Web browsers do not bother with DNSSEC (which remains quite very relevant despite what the article doesn’t says. It is true that this particular BGP hijack doesn’t change your endpoints’ DNS records (such as A, AAAA, PTR, NS, MX). But this attack did not attempt to fake the DNS CAA at all, which would have protect web browsers; Faking CAA record was not needed then, but it will be leverage next. So DNSSEC, being secured as they are now however is not culpable there nor would they ever be. It is only the DNSSEC-unprotected CAA record that will be the next target. The Culpability is the malicious PKI substitution which occurred during that event is the fault of web browser, but it is NOT the fault of the TLS protocol, nor HTTP; web browser is guilty. It is the design of using TLS function calls by the application. TLS API, while makes heavy use of PKI certificates, leaves out PKI management to the “other people’s problem” category. TLS protocol and its API is not the problem, they still work as designed. PKI management is the problem. By direct user experience, web browser is also the problem. However … your data still can survive a BGP hijack (DNS or not) as intact and securely so if your use case for B2B calls for a secured endpoint using HTTPS/mTLS that has the following aspects: - use a pair of server and client PKI and its public key stored on opposite ends for use with mTLS (mutual two-way server/client TLS) - DNSSEC resolver on both ends configured in cacheless authoritative-only lookup mode (no forwarder) with the 13 Root Server key configured/compiled in. - Deploy the DNS CAA record for your PKI and ensure that each of the chained PKI uses CAA and ensure that all that needed CAA are secured that under DNSSEC - your endpoint app properly use TLS/SSL function calls AND verified the PKI chains but not before verifying DNSSEC-only DNS queries needed for chain validation. It remains arguable that given above, one can still use a 3rd party intermediate CA to sign your intermediate CA in which to deploy your needed PKIs for your endpoints. I am now asserting that if you separate your server PKI and client PKI to each of two different vendors, you should get a pretty good security provided that you figured out your own PKI distribution securely and that your own intermediate CA PKI is also imprinted into your app’s own mTLS. That summary should help your data survive a BGP hijack in your “B2B”pipeline. A bit safer than IPSec. Thank you.