Deep Packet Inspection and Internet censorship in Azerbaijan

April 1, 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 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 are reachable via BGP via AS29049

*> x.x.x.x 110 0 ::: :::: :::: 29049 57293 i

Who is being blocked?

Three websites are currently blocked:, and

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, and web services.

DPI Signatures

  • HTTP sessions are identified by looking into the “Host: ” header of the HTTP connection and mapping the 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:”

  • 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:
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 (

openssl s_client -connect

Now run the very same command but forge TLS to nclude as servername (SNI)

openssl s_client -connect -servername

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