Hacker News new | ask | show | jobs
by galliher 2094 days 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".
1 comments

Yes! That's a great observation

However, the reason I went for probing the entire path is because the TTL itself can be spoofed

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.