Investigating TLS blocking in India
Gurshabad Grover and Kushgra Singh collaborated with Simone Basso (OONI) to investigate TLS-based blocking in India. The research report was published on OONI's blog. It was edited and reviewed by Maria Xynou and Arturo Filastò.
Summary
This report investigates Transport Layer Security (TLS)-based blocking in India. Previous research by the Centre for Internet & Society, India (CIS) has already exposed TLS blocking based on the value of the SNI field. OONI has also implemented and started testing SNI-based TLS blocking measurements.
Recently, the Magma Project documented cases where CIS India and OONI’s methodologies could be improved. They specifically found that blocking sometimes appears to depend not only on the value of the SNI field but also on the address of the web server being used. These findings were later confirmed by OONI measurements in Spain and Iran through the use of an extended measurement methodology.
We were therefore curious to see whether such an extended methodology would discover further cases of TLS blocking in India. To answer this research question we ran experiments on the networks of three popular Indian Internet Service Providers (ISPs) (ACT Fibernet, Bharti Airtel, and Reliance Jio) which account for over 70% of the internet subscribers in India.
We recorded SNI-based blocking on both Bharti Airtel and Reliance Jio. We also discovered that Reliance Jio blocks TLS traffic not just based on the SNI value, but also on the web server involved with the TLS handshake. Moreover, we noticed that ACT Fibernet’s DNS resolver directs users towards servers owned by ACT Fibernet itself. Such servers caused the TLS handshake to fail, but the root cause of censorship was the DNS.
We also document that one of the endpoints we tested,
collegehumor.com:443, does not allow establishing TCP connection from
several vantage points and control measurements. Yet, in Reliance Jio,
we see cases where the connections to such endpoints complete
successfully and a timeout occurs during the TLS handshake. We believe
this is caused by some kind of proxy that terminates the TCP connection
and performs the TLS handshake.
Read the full research report on OONI's blog.
