Open xhdix opened 4 years ago
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.
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.
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.)
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.
@wkrp to my knowledge, curl
does not yet support ESNI. Iran has had robust SNI filtering for a little while now though.
In TCI:
In MCI
It seems to be blocked in MCI but this does not happen right after Client hello!
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
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:
JA3
and JA3S
?Is this the reason why quic protocol does not work in Iran?
@mokhtarabadi : no, they blocked some UDP endpoints no matter what is it.
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
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
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 :
Irancell (AS44244) :
In Apr 15th :
Now :
Shatel (AS31549) :
In Apr 15th :
Now in Shatel, it is almost impossible to open the Cloudflare site after activating ESNI!
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 :
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)