The other day at work, we received issues from customers. They told us that they couldn´t access to their web Instance. In all the cases, the origin was the same country.
The first thing that I ask, is to give me a screenshot of the error, but it wasn´t a great help.
We also asked for a telnet instance 443
My surprise was that, telnet worked well, but then….
With curl doesn´t work well. Maybe It´s pointing to something related to SSL.
We decided to sniff on the client side, loadbalancer, etc…
We could see RSTs just after the client Client Hello. It indicates that it could be a problem with the handshake, maybe ciphers, etc etc..
Here I don´t have the loadbalancer .pcap files, but as far as I remember, in the loadbalancers we also received RSTs. So what´s sending the RSTs?
Let´s examine the Client Hello inside the .pcap file.
Let´s go down until Server Name Indication extension. After server Name length. It should be the name of the severname (I deleted in this case)
What´s the Server Name Indication Extension: Server Name Indication, often abbreviated SNI, is an extension to TLS that allows multiple hostnames to be served over HTTPS from the same IP address.
Let´s try to change the headers with curl or openssl.
Here you could see how it worked. Why? Let´s go and open the new .pcap file.
In this new .pcap we can´t see the the SNI extension and we can´t also see any of the RST
Ok, if we have more than one site in that ip address it would be a mess, because we would access to the first loaded certificate, but in this case we only wanted to see that the problem was with SNI filtering.
Here you have a nice website to check a website from different agents. In this case agents in China and other regions, to see the differences.
SNI filtering is used very often by Internet providers to block access to torrent sites or similar. In this case it might be related to the great firewall (China).