Live data from Hacker News

Identifying Airtel middleboxes that censor HTTPS traffic

iamkush.me

1–10 of 130 posts

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#3
post #2

The 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

#5

Does 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

#6

Does 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

Agreed and since TLS 1.3 is still work in progress the chances are slim that you will find a blocked website that meets your criteria. Great article, very accessible. Thanks!

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#7
post #2

The 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 :)

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

#8
post #7

Earlier 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?

Yes, that was the case

Re: Identifying Airtel middleboxes that censor HTTPS traffic

#9

Does 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

If they block ESNI, it's likely all ESNI requests would be blocked, because they can't tell if its a blocked site or not. (it'd be possible they only apply ESNI-blocking against IPs associated with blocked sites, but that seems unlikely)
Post reply on HN