Re:Identifying Airtel middleboxes that censor HTTPS traffic
by galliher on Tuesday September 29, 2020 @09:12AM
(#24627365)
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".
[ Parent
| on HN ]
Re:Identifying Airtel middleboxes that censor HTTPS traffic
by justDankin on Tuesday September 29, 2020 @09:21AM
(#24627454)
Yes! That's a great observation
However, the reason I went for probing the entire path is because the TTL itself can be spoofed
Re:Identifying Airtel middleboxes that censor HTTPS traffic
by galliher on Tuesday September 29, 2020 @09:31AM
(#24627576)
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.