3 ms·
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 synchr
by galliher 6y ago
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".
- justDankin 6y agoYes! That's a great observation However, the reason I went for probing the entire path is because the TTL itself can be spoofed
- galliher 6y agoAgreed, 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.