If a TLS request triggers an unexpected response it is interesting to check the role of the SNI field in triggering the behavior. SNI may be both “expectedly” absent (e.g. https://1.1.1.1) and “expectedly” present (TLS1.2, TLS1.3 without ESNI). The outcome of the following tricks may be inspected:
- absent SNI may be filled with a related1 domain (e.g. “one.one.one.one” for “1.1.1.1”)
- absent SNI may be filled with an unrelated domain (e.g. “example.org”)
- present SNI may be dropped
- present SNI may be replaced with a related1 domain that also has a risk to be censored
- present SNI may be replaced with an unrelated domain, but control measurement should check for “expected” server reply in this case
1: a domain “related” to the IP address may be extracted from a dataset like the Rapid7 Forward DNS, some data may also be extracted from the TLS certificate presented via a SNI-free query
- AS8997, Russia blocks requests to https://1.1.1.1 without SNI field, but requests with SNI=one.one.one.one pass
- AS8997, Russia blocks requests to https://rutracker.org when SNI field exists, but requests to the same endpoint without an SNI field pass
- Iran blocked www.instagram.com using information both from SNI and unencrypted Server Certificate, these two cases have different timing patterns