galliher

It’s still imperfect AFAIK. Your provider may or may not have upstream routers speaking BGP and running RPKI validation at ASN boundaries which validate prefixes against certificates blessed by the appropriate RIRs (maybe analogous to CAs for routes). Since you mentioned Cloudflare I’ll just cut to the chase and link an instance of their blog on the subject : https://blog.cloudflare.com/rpki/

First example of imperfection which springs to mind first for me are misconfigurations in the network which ultimately allow for leaks to be accepted. IMHO this compounded with the nature of DNS recursion across name authorities on the far side of any ASN boundaries (that may be out of your provider’s control) makes any assurances weak at best when searching for name resolution trust.

(Edit : oh and I think DNSSEC is probably another layer worth considering. But it’s also inconsistently deployed.)

(Second edit : Sorry! I made a mental leap to RPKI when I saw “BGP hijack”, “certificate”, & “IP addresses”. IIRC a webserver’s x509 certificates don’t contain an OID of any inaddr{,6}, nor cidr type. i.e. a browser doesn’t verify a httpd’s ip against anything in the cert vended. Only that the cert is signed by a chain leading to a CA trusted by the client/browser(s).)

> faster

Check out {send,recv}mmsg before something io_uring-ish imho. One syscall/ctxt, many packets.

Agreed, it's flimsy. Certainly a bit more effort for them spoof it correctly though. Would need to watch traffic on the path back per flow to isolate the number of prior decrements to the TTL leading up to MitM, and then store that value until such time that it sees an SNI it cares about / it's time to generate a reset.

This is pretty clever! The reset within airtel_103.224.212.222_fullhd720.com.pcap arrives with IP time-to-live of fifty-seven while the segment carrying synchronize | acknowledge flags arrived with a time-to-live of forty-four. So without any active probing, and some educated guesses around default IP time-to-live values @ 1<<[6..8] you could could conclude that the reset originated fourteen hops closer to the capture than other packets in same five-tuple defined "flow".

The "Connection Tracking" portion of http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-net... provides some insight here and describes a method to avoid connection tracking in EC2's firewall.