Reliance Jio is using SNI inspection to block websites

This blogpost was written by Gurshabad Grover and Kushagra Singh, and edited by Elonnai Hickok.

Background

In April this year, several Jio users were puzzled to find that Reddit and Telegram were being blocked by the ISP. Around the same time, Sushant Sinha was perplexed to note that those using Jio connections were unable to access IndianKanoon.com, the legal database he founded and runs.

These experiences of arbitrary web censorship are the natural conclusion of an opaque legal framework that allows the Government of India to order ISPs to block certain websites for its users. The Central Government draws such powers from sections 69A and 79 of the Information Technology (IT) Act and the rules issued thereunder. Notably, the “blocking rules” issued under Section 69A describe an executive-driven process, and further mandate the confidentiality of blocking orders issued to intermediaries. These rules have meant that it is next to impossible for netizens to know the complete list of websites blocked in India and the reasons for such blocking.

Pertinently, the blocking rules do not mandate ISPs to use any particular technical method to block websites. This has meant that Indian ISPs are at liberty to pick whatever filtering mechanism they wish, which has had implications for how internet users experience and circumvent web censorship. Researchers at IIIT-Delhi have already documented Indian ISPs are using two methods:

1. Domain Name System (DNS) based blocking
   Users trying to access websites usually contact the ISP’s DNS directory to translate a human-parseable address like ‘example.com’ to its network address ‘93.184.216.34’. Some ISPs in India, like BSNL and MTNL, respond with incorrect network addresses to the users’ queries for websites they wish to block.

2. Hypertext Transfer Protocol (HTTP) header based blocking
   HTTP is the most popular way to transmit web pages. Since classic HTTP communication is unencrypted, ISPs can monitor for the website’s name that is attached (the HTTP Host header field) to such traffic. ISPs like Jio, Airtel and Vodafone monitor this field for names of websites they wish to block, intercept such requests, and return anything they wish as a response.

Generally, ISPs’ use of either method directs users to a censorship notice when they find that the user is trying to access a ‘blocked’ website.

Image 1: The notice served by Jio (through HTTP-header based filtering and injected response) when a user tries to access a blocked website.

In this blogpost, we document how Jio is using, in addition to HTTP-based blocking, another censorship method: Server Name Indication (SNI) inspection. First, we explain what the SNI is. Then, we detail how you can independently confirm that Jio is using information in the SNI to block website access. In the end, we explain the implications of Jio’s decision.

 

SNI Inspection

Transport Layer Security (TLS) is a cryptographic protocol for providing communication confidentiality and authenticity, commonly used for encrypting web traffic (as done in HTTPS). The SNI, defined first in RFC 4366 and then in RFC 6066, is an extension to TLS designed to facilitate the hosting of multiple HTTPS websites on the same server. While establishing a secure connection (a TLS Client Hello), a client just fills in the SNI attribute with the hostname of the website it wishes to connect to.

SNI, unfortunately, travels on the network in cleartext, i.e. network operators can not only see the websites you’re visiting, but also filter traffic based on this information. The use of SNI inspection in state-directed web censorship was not very common until recently. Only this year, the use of SNI inspection to censor websites was documented in China and South Korea.

In the Indian context, the aforementioned paper, the researchers note that in Indian ISPs they investigated (including Jio), they “observed fewer than five instances of HTTPS filtering which were actually due to manipulated DNS responses [...], and not because of SNI field in TLS [...].” However, as the next section documents, Jio is now in fact using SNI-inspection based filtering.

 

The test

To run our tests, we can take advantage of the fact that Google's server is configured to respond successfully to TLS connection attempts even if we send an SNI with a website’s name that it does not host on that server.

Using OpenSSL's s_client utility, we attempt to establish a TLS 1.3 connection with an IP address (216.58.196.174) corresponding to google.com. However, instead of specifying 'google.com' in the SNI, we specify a potentially blocked website (PBW) 1337x.be.  

openssl s_client -state -connect 216.58.196.174:443 -servername 1337x.be -tls1_3

Two important notes here:

• We are not connecting to the PBW at all! This simple approach is allowing us to rule out other censorship methods (like DNS, HTTP, and even IP/TCP-level blocking) from interfering with our results.

• We’re using TLS 1.3 to make our connections. This is because in older versions of TLS, the server passes its certificate to the client in cleartext. ISPs may also be using that information to block websites if older TLS versions are used. Using TLS 1.3 allows us to ensure that ISPs are indeed using SNI inspection to block websites.

We notice that when we specify a PBW in the SNI, we receive a TCP packet with the RST (reset) bit set almost immediately after the connection is established, which closes the established connection. Of course, a plausible explanation could be that the Google server itself might be resetting the connection upon realising that it does not host the PBW. However, this is neither the expected behaviour as per RFC 6066, nor do we notice the server doing so in all cases where we specify a SNI for a website that it is not hosted on the server. For example, when we specify facebook.com as the SNI, not only are we able to complete the TLS handshake but we're also able to make subsequent requests to the server after completing the handshake (albeit receiving an expected "not found" error in response). 

You can find and compare the OpenSSL requests and responses for a PBW (1337x.be) and an uncensored website (facebook.com) here.

A caveat here is that we do not always notice such behaviour. For instance, while trying to detect such censorship, we found that connecting to one of Google’s IP address (216.58.196.174) resulted in connection resets. Whereas doing the same with a different IP address which google.com resolves to (172.217.161.14) resulted in successful connections. This seems to suggest that Jio has employed a limited number of middleboxes inspecting and filtering traffic based on the SNI.

 

Implications

The scale of users impacted by this technical choice is huge: according to data released by the Telecom Regulatory Authority of India last month, Jio is the most popular ISP in India. It currently serves 331.25 million internet subscribers in the country, which constitute 49.79% of internet subscribers in India. If Jio installs middleboxes at enough points across the regions it serves, all Jio customers potentially face SNI-based censorship.

The technical methods that ISPs use to implement website censorship have direct implications for how easily users can access blocked websites. Working around DNS spoofing, for example, can be fairly simple: one can change system settings to use to one of the many censorship-free DNS resolvers. The paper by IIIT-Delhi researchers also found that circumventing HTTP-based censorship is easy in India because of how ISPs are implementing the mechanism. The currently documented ways for clients to bypass SNI-based censorship is by either not specifying an SNI or specifying a modified SNI while connecting to the blocked website. However, both these approaches can be futile as the server hosting the website might close the connection upon observing such an SNI. To effectively circumvent SNI-based censorship, Jio users may have no choice but to resort to using Tor or VPNs to access blocked websites. 

Another aspect is how the technical method chosen by ISPs can have implications for transparency in censorship. As pointed out in the beginning of the blogpost, the legal framework of web censorship in India lacks transparency, fails to make the Government accountable for its orders, and places no obligations on ISPs to be transparent about the websites they block or the methods they use for doing so. The choice of Jio to use SNI-inspection based filtering to implement web censorship aggravates this already-opaque system because it is technically impossible to serve censorship notices using this method. TLS is designed in a way that clients abort connections when they detect interception and on-path attacks. Thus, Jio can only create connection failures when it wishes to block websites using SNI inspection. Since users facing SNI-based censorship will not see censorship notices, they may be left confused as to whether the website they wish to access is unavailable, or being blocked by the ISP.

Image 2: Error users will face when Jio censors websites with SNI-based filtering.

The way forward

There is already ongoing work in the TLS working group at the Internet Engineering Task Force to encrypt the SNI. When there is wide deployment of encrypted SNI, we can expect SNI-inspection based filtering to be ineffective. However, the group currently faces several thorny design problems; of primary relevance in this context is how TLS connection attempts that use encrypted SNI should not “stick out”, i.e. such traffic should not be easily distinguishable from TLS connection attempts that use cleartext SNI. Traffic relying on implementations of encrypted SNI that “stick out” can be filtered out, as South Korean networks are doing already. Hopefully, we can expect that no Indian ISP will take such drastic measures.