ESNI blocking in Iran or packets white list

[xhdix]

trafficstars

For several months now, there has been evidence that some ISPs in Iran are intermittently blocking ESNI. The highest blockage was observed in MCI (AS197207) and then in Shatel (AS31549). Because behaviors are different for each request and for each ISP, no definite conclusion can be drawn, but severe disorders are certain! Probably the main problem is this: https://github.com/net4people/bbs/issues/10#issuecomment-532035677

What happens with ESNI: DPI detects request to the IP address listed in the registry. DPI does not detect any SNI in TLS ClientHello packet and rejects the connection.

The following two addresses are used for testing: https://www.cloudflare.com/ssl/encrypted-sni/ https://www.cloudflare.com/cdn-cgi/trace

TCI (AS58224) :

Strange behavior is observed in TCI, that sometimes in a single moment, you can access a website with one browser and you can't with another browser!

In Apr 14th :

In May 4th :

Now :

fl=71f376
h=www.cloudflare.com
ip=93.117.123.***
ts=1593702754.022
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
colo=FRA
http=http/2
loc=IR
tls=TLSv1.3
sni=encrypted
warp=off

Irancell (AS44244) :

In Apr 15th :

Now :

fl=71f430
h=www.cloudflare.com
ip=5.123.20.***
ts=1593707753.434
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
colo=FRA
http=http/2
loc=IR
tls=TLSv1.3
sni=encrypted
warp=off

Shatel (AS31549) :

In Apr 15th :

Now in Shatel, it is almost impossible to open the Cloudflare site after activating ESNI!

fl=71f328
h=www.cloudflare.com
ip=151.246.179.***
ts=1593717810.236
visit_scheme=https
uag=Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
colo=FRA
http=http/2
loc=IR
tls=TLSv1.3
sni=encrypted
warp=off

Capture for opening: https://blog.cloudflare.com/encrypted-sni/

The packet with TTL 47 has a duplicate IP.ID of the previous packet. I've seen this behavior before in TCI, but with TTL 114:

MCI (AS197207) :

In MCI, the situation is worse than what we saw in Shatel! There is no stability!

In Apr 14th :

Now :

fl=71f224
h=www.cloudflare.com
ip=89.198.58.***
ts=1593705362.508
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
colo=FRA
http=http/2
loc=IR
tls=TLSv1.3
sni=plaintext
warp=off

This capture is related to an Outline server that is blocked in MCI! (The Outline app manually closed after 300 seconds.)

Here, sometimes after <SYN,ACK>, the TTL changes from ~40 to ~60! I mean, the way they block services has changed a lot!

(Updated : 3:04 PM, Friday, July 3, 2020)

[wkrp]

My first thought was that this may be a manifestation of the new protocol filter on ports 53, 80, and 443: https://geneva.cs.umd.edu/posts/iran-whitelister/. The protocol filter report also says that interference is intermittent and does not affect all IP addresses equally. But on closer inspection, this seems to be something different, as the protocol filter doesn't look at the part of the ClientHello that would change with ESNI:

After the first 5 bytes of the packet (the type, the version, and the length, 1, 2, and 2 bytes respectively), the whitelister does not look at any contents of the Client Hello. Writing garbage bytes to the remaining bytes of the Client Hello does not trip the whitelister.

In the Shatel capture, you are right, the PSH/ACK with a different TTL and a IP ID copied from the client's ClientHello packet is weird and looks like an injection. There's no ServerHello, but interestingly 15 seconds later the server sends a FIN with what looks like a legitimate TTL.

I am not sure what the purpose is served by injecting a 0-length ACK packet, after the connection is already established. I thought it might be an attempt at sequence number desynchronization, but you would expect to see the legitimate server response as well, if that were the attack. Instead, it looks like the client→server data packet is never reaching the server; and therefore the server never responds and eventually FINs.

[wkrp]

I found a couple of tweets with more evidence of ESNI blocking in Iran.

2020-08-09 https://twitter.com/AliMirjamali/status/1292498063425187840 (archive)

Blocking ESNI & TLS 1.3 has been evaluated for few months here in Iran. I enabled it few months ago on my local update mirror (hosting Arch and a bunch of other Linux Distros) and started to receive a lot of complains from users. Here is another example: 2020-08-05 https://twitter.com/haghighi_ahmad/status/1290921894515015680 (archive)

دیووث اینقدر گوه نزن به tls
بی ناموس #فیلترنت
از سرور‌هایی که امریکا هستن یکی در میون اینطوری میشه.

Do not so much wedge tls
Dishonorable #filternet
This is how one of the servers in the United States is.

[xhdix]

Does curl support ESNI?! This seems to be SNI blocking. (perhaps, as in recent months, more sites are being blocked for planning to slowly cut off the Internet. Any site that people use will be blocked.)

[wkrp]

Does curl support ESNI?! This seems to be SNI blocking.

Hmm, you may be right. I guess the sub-tweet doesn't claim to use ESNI, and the tweet quoting it doesn't provide any specific evidence.

[Kkevsterrr]

@wkrp to my knowledge, curl does not yet support ESNI. Iran has had robust SNI filtering for a little while now though.

[xhdix]

In TCI:

In MCI

It seems to be blocked in MCI but this does not happen right after Client hello!

[Kkevsterrr]

Does it take a certain amount of time for censorship for censorship to kick in, or is it a certain # of packets? For the GFW, it takes 1-2 seconds for censorship to kick in, i'm curious if that's the same here

[xhdix]

With Firefox:

With esni.py :

With Firefox and esni.py at the same time:

It seems that the handshake should end and only the same Stream index enters the blackhole.

What I don't know:

1. Does it depend on the number of packets?
2. Does it depend on JA3 and JA3S?
3. Does it really depend on finishing the TLS handshake and starting the HTTP exchange?
4. Does it depend on the size of the exchanged data?

[mokhtarabadi]

Is this the reason why quic protocol does not work in Iran?

[xhdix]

@mokhtarabadi : no, they blocked some UDP endpoints no matter what is it.

[xhdix]

In recent days, it can be said that 80% of the Internet is blocked in Iran. Even Iranian services that are hosted outside of Iran or hosted inside but using a domain other than .ir are blocked. It does not matter if it is HTTP or SSH, the behavior is almost the same: packet injection (with fingerprint) The fingerprint is the same as #47 and I explained here about TCP cases: https://github.com/net4people/bbs/issues/98#issuecomment-1114011496

Dropping Server-Hello and FIN and reply to client's requests:

Injecting one PSH,ACK packet and then null route:

Injecting two PSH,ACK packet after 33 seconds (or 44, 15, ... seconds) in SSH then null route;

Test results of one of the cases with TraceVis. When blocked by this method and after unblocked:

packet-injection-AS58224-tracevis-20220623-1144_combined.zip