Identifying Airtel middleboxes that censor HTTPS traffic
1–10 of 130 posts
Re: Identifying Airtel middleboxes that censor HTTPS traffic
#2Re: Identifying Airtel middleboxes that censor HTTPS traffic
#3The TTL field isn't cryptographically protected though, so it should be very possible that there's an actor after Airtel which does the censoring, no?
If a box was censoring after Airtel, we would have received a clean response (ICMP timeout) at hop k as well. Of course, the TTL itself can change during the run, but that wouldn't happen for so many cases :)
Re: Identifying Airtel middleboxes that censor HTTPS traffic
#4Re: Identifying Airtel middleboxes that censor HTTPS traffic
#5Does Airtel block TLS 1.3 with the encrypted SNI extension enabled? https://blog.cloudflare.com/encrypted-sni/
IMO the only way to do that would be to either (i) block the IP (high collateral blocking) or (ii) block TLS 1.3 itself (GFC does this).
A major blocker in answering this is finding a potentially blocked website that also supports TLS 1.3
Re: Identifying Airtel middleboxes that censor HTTPS traffic
#6Does Airtel block TLS 1.3 with the encrypted SNI extension enabled? https://blog.cloudflare.com/encrypted-sni/
I haven't been able to test that yet, neither am aware of any research which answers that question. IMO the only way to do that would be to either (i) block the IP (high collateral blocking) or (ii) block TLS 1.3 itself (GFC does this). A major blocker in answering this is finding a potentially blocked website that also supports TLS 1.3
Re: Identifying Airtel middleboxes that censor HTTPS traffic
#7The TTL field isn't cryptographically protected though, so it should be very possible that there's an actor after Airtel which does the censoring, no?
Using the TTL, we figured out that the censor kicks in at the kth hop. This kth box belonged to Airtel. If a box was censoring after Airtel, we would have received a clean response (ICMP timeout) at hop k as well. Of course, the TTL itself can change during the run, but that wouldn't happen for so many cases :)
Re: Identifying Airtel middleboxes that censor HTTPS traffic
#8Earlier quoted context omitted.
Using the TTL, we figured out that the censor kicks in at the kth hop. This kth box belonged to Airtel. If a box was censoring after Airtel, we would have received a clean response (ICMP timeout) at hop k as well. Of course, the TTL itself can change during the run, but that wouldn't happen for so many cases :)
If you used an allowed domain name, did you get TTL expired messages back when using TTL=5/6/7/8?
Re: Identifying Airtel middleboxes that censor HTTPS traffic
#9Does Airtel block TLS 1.3 with the encrypted SNI extension enabled? https://blog.cloudflare.com/encrypted-sni/
I haven't been able to test that yet, neither am aware of any research which answers that question. IMO the only way to do that would be to either (i) block the IP (high collateral blocking) or (ii) block TLS 1.3 itself (GFC does this). A major blocker in answering this is finding a potentially blocked website that also supports TLS 1.3
Re: Identifying Airtel middleboxes that censor HTTPS traffic
#10https://i.postimg.cc/SqkRhpRC/Mozilla-Firefox-29-09-20-w-PA....