2021-basso-measuring
findings extracted from this paper
-
In AS45090 (China), the Cloudflare CDN IP 104.16.248.249 succeeds 100% of the time with SNI 'cloudflare-dns.com' but triggers TLS handshake resets 93% of the time with SNI 'mozilla.cloudflare-dns.com'. Follow-up measurements using those same SNIs against unrelated HTTPS servers (example.org, hbl.fi) reproduced the same resets, confirming that the GFW performs SNI-keyed TLS blocking independent of the destination IP.
-
Dominant failure modes differ systematically by country: China (AS45090) shows connect timeouts in 75% of DoT failures (IP-level blocking); Kazakhstan (AS48716) shows post-TLS-handshake timeouts in 72% of DoT failures (likely ACK or segment discard after handshake); Iran (AS197207) shows TLS handshake timeouts in 80% of DoT failures. Packet capture analysis confirmed that timeouts during and after the TLS handshake correspond to unacknowledged TCP segments, not connection resets.
-
MCI (AS197207, Iran) intercepts cleartext DNS and returns the bogon address 10.10.34.36 for dns.adguard.com A queries regardless of which upstream resolver is used (system, 8.8.8.8, or 9.9.9.9), and intercepted queries never reached a researcher-controlled DNS-over-UDP server. This bogon falls in the same /24 documented in prior Iranian censorship research. Additionally, SNI blocking for dns.adguard.com was confirmed independently on both port 853 (DoT) and port 443 (DoH).
-
In AS197207 (Iran, MCI), approximately 50% of DoT endpoints failed consistently — the only case across all tested ASN/protocol combinations where failure exceeded 20%. In Kazakhstan (AS48716) and China (AS45090), more than 80% of DoT and DoH endpoints were always reachable.
-
In AS197207 (Iran), Google's DoT endpoint 8.8.4.4:853 is blocked 100% of the time while 8.8.8.8:853 is always accessible, regardless of SNI value. TLSv1.3 handshake analysis (hiding server certificates) confirmed no SNI correlation, establishing that Google's DoT blocking depends solely on the destination IP endpoint.