1st April 2017
Active connection teardowns
Starting the Monday, 27th of March 2017 at 11.30 AM (UTC), we monitored a sudden drop of visitors to the website azadliq.info coming from inside Azerbaijan. The website receives 70% of the total traffic from inside Azerbaijan and on Monday the traffic suddenly dropped to 30-40%.
At the same time one of our sensors detected a sudden increase of “short sessions” and “reset traffic” coming from several providers inside of the country. Connections arriving from inside Azerbaijan were terminated suddenly after completing the first communication handshake.
In the evening of Monday, 27th we received a few screen shoots from readers confirming the problems. Browsers receiving the RST traffic display the error message “ERR_CONNECTION_RESET”
This type of behavior is not new to us as we have seen these traffic patterns in the past when dedicated equipment is placed to interfere actively with web traffic.
We checked all the providers affected by the traffic disruption and collected their Autonomous System Names:
By looking into different global routing tables, we identified AS29049 as the common transit provider of the affected traffic.
For example, all subscribers from provider KATV1 (AS57293), a cable TV provider in Azerbaijan coming from network 184.108.40.206/16 are reachable via BGP via AS29049
*> 220.127.116.11/16 x.x.x.x 110 0 ::: :::: :::: 29049 57293 i
Who is being blocked?
Three websites are currently blocked: www.azadliq.info, www.azadliq.org and www.meydan.tv
How does the blocking work?
Inside of Delta Infrastructure there is a dedicated appliance that is monitoring all incoming and outgoing traffic.
The device keeps track of each of the TCP sessions independently of port number.
The device tracks both HTTP and HTTPS sessions associated with azadliq.info, azadliq.org and meydan.tv web services.
- HTTP sessions are identified by looking into the “Host: ” header of the HTTP connection and mapping the azadliq.info or any subdomain. SIGNATURE: A signature of the DPI matching is that the device will also match the domain name with a dot “.” at the end, as in “Host: azadliq.info.”
- HTTPS sessions are identified by looking into the servername extension during the initial TLS negotiation
TLS Server Name Indication Extension
When a HTTP GET Request is identified the packet with the “Host” header is dropped and two Reset packets are sent to the end points of the connection to force the shutdown of the connection.
When a HTTPS TLS negotiation is identified the packet with the “Client Hello” header is dropped and two Reset packets are sent to the end points of the connection to force the shutdown of the connection.
A great document that helped us to understand the role of RST packets is available here
How can you independently verify that such traffic monitoring and disruption is taking place?
If you have access to a computer inside the country, it is easy to record the traffic and see that “Reset Packets” arrive to the browser as soon as a connection is established.
If you do not have access to a computer inside Azerbaijan, you still have means to verify the blocking of the connections as the Deep Packet Inspection is also taking place in “all incoming” connections into the country.
In order to see the TLS dropper in action you can just place a TLS connection against any HTTPS server inside the country and send one of the blocked sites as Server Name Identification.
Google Cache inside Azerbaijan is also under Deep Packet Inspection
For example, pick a Google Cache Server which traffic passes via Delta Telecom AS29049 and modify the TLS header extension that includes the servername to invoke any of the blocked sites.
Let us take for example
network route:18.104.22.168/16 descr: Azercell Telecom / Core Network / LTE Pool #1 origin: AS31721
In this network are hosted the Google Cache Servers.The provider AS31721 is reachable via Delta AS29049
Place a standard TLS connection against Google Cache Server cache.google.com (22.214.171.124)
openssl s_client -connect 126.96.36.199:443
Now run the very same command but forge TLS to nclude azadliq.info as servername (SNI)
openssl s_client -connect 188.8.131.52:443 -servername www.azadliq.info
The result is that a Reset (RST) is automatically injected by the filtering system to block the connection. Such packet is not injected if other domains are used in the servername extension
Where is the device?
In order to determine the location of the malicious device, we recorded multiple packet traces and observed that once the browser inside Azerbaijan places a HTTP web request against www.azadliq.info a RST packet is artificially injected to tear down the connection.
By calculating the difference of time between the web requests and the received “resets”, we are able to calculate the proximity of the DPI device. The device is just 1.5 ms away.
How can you help?
If you are reading this article and know more about the technology used reach to us. https://www.qurium.org/contact