ESNI blocking in Iran or packets white list about bbs HOT 11 OPEN

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: #98 (comment)

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

from bbs.

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

from bbs.

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.

from bbs.

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.

from bbs.

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

from bbs.

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.

from bbs.

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

from bbs.

In TCI:

In MCI

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

from bbs.

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?

from bbs.

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

from bbs.

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

from bbs.