SNI filtering by Indian ISP Reliance Jio

There’s a report today about SNI filtering by the largest ISP in India.

Reliance Jio is using SNI inspection to block websites
Gurshabad Grover, Kushagra Singh, Elonnai Hickok

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.

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).

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.

I was a little surprised to see this report, because I had thought (or assumed) that Indian ISPs were already using SNI filtering. But the paper by Yadav et al. from 2018 does not provide evidence of SNI filtering. And a 2017 report of the blocking of archive.org says that HTTPS was completely unblocked (which I confirmed using OONI measurements). So I guess this really is something new.

Another thing I found surprising was that they said they are getting the TCP RST after the TLS ServerHello. I’ve never seen that behavior before, except when the certificate was used for censorship. But that was not the case here, since they used TLS 1.3, which encrypts the certificate.