How is Iran blocking Tor?
Note that currently it looks like there might be more than just one filtering technique in place. The following was the initial report describing one possible filtering technique and this comment describes another technique.
Some users reported that the Iranian ISP "Pars Online" is (partially?) blocking Tor.
One user looked into it and believes that Tor is identified based on the server_name extension in the TLS client hello. It looks like DPI boxes extract the domain and do a DNS lookup for it. If the domain resolves and the relay/bridge is listening on port 443, the connection passes. Apparently, an omitted server_name or a server_name rewritten to www.google.com passed the filter.
Obfsproxy seems to work.
Some open questions:
- Can we reproduce and verify the existing hypothesis?
- Is this an attempt to only allow HTTPS and no other SSL/TLS-based protocols? Or is it targeting only Tor?
- Can we modify brdgrd to evade the server_name extraction?
- Is this type of block limited to Pars Online?
Activity
After several attempts to investigate this issue, I am unable to reproduce this ticket currently. I would suggest that there is a significant need for more detailed information on what part of the Pars network these reports are coming from and what the user experiences.
Is this type of block limited to Pars Online?
I was able to bootstrap a clean installation of Tor from within Iran yesterday. While I have been led to believe from discussions and historical examples that most DPI occurs at AS12880, the international gateway, it does appear evident from recent government RFQs that they are interested in moving this administration to the ISP level. I have now arranged a server with Pars and am attempting to reproduce -- without luck so far.
Three notes:
- There is no significant change in the number of users directly connecting from Iran under metrics[1]. ParsOnline is something akin to the Comcast of Iran, and disruptions in the connectivity would be fairly evident.
- There have been a few number of complaints regarding HTTPS disruption on social media and elsewhere since the unblocking of Google, but these have been hard to pin down and nonspecific to Tor.
- If there is active probing, we should setup a bridge with a FQDN, trigger a probe and watch for connections.
- It would be useful to clarify the manner of the disruption the user is experiencing: are they able to stay connected to a bridge for a limited amount of time or unable to create a circuit at all? In the China example wasn't there queuing on probes and thus a few minutes of access?
I'm certainly not dismissing the ticket, it's just difficult find data at this moment.
Trac:
Username: cda
A user was able to find out more. The following is my summary of what we were told on IRC. However, keep in mind that the following was indeed tested but should not be considered as fact at this point.
It still looks like the
server_nameextension (SNI) is crucial. Other fingerprints could not be found so far. The user tested this theory by adding a bogus hostname to /etc/hosts pointing to an existing web server (for example Google's). Apparently, the TLS handshake belonging to the bogus host connection was blocked for all major browsers (Opera, IE9, Chrome, Firefox16). A middle box might have tried to resolve the bogus hostname which failed - resulting in the block.Now regarding the concrete implementation - once again, this is merely a hypothesis. Some sort of DNS cache might be used by the middle boxes. It would make sense since it's expensive to run DNS queries for every (suspicious) TLS handshake. The user reported that even "benign" non-Tor handshakes sometimes did not work. But they did work later. One explanation would be that the middle boxes had a cache miss and had to populate the cache with the new DNS record.
Furthermore, the user could connect to a (previously blocked?) relay by creating a dyndns record and pointing it to the relay's IP address. The first handshake failed (cache miss?) but the next day it succeeded.
Also, the user thinks that there might be whitelisted IP address blocks where middle boxes do not mess with handshakes.
I set up a private bridge running a modified version of brdgrd. It should make the Tor client split the
server_nameextension in two TCP segments. The bridge worked for the user but this is just anecdotal evidence. Please contact me if you want the bridge descriptor.I talked to a friend of mine about this problem, this is the translation of what he wrote me:
"It could be not specific to Tor. Pars Online doesn't pass packets of over 1400 bytes. Few customers of us had complained about Pars Online, we set the mtu of our servers to 1400 and the problems were solved."
I know that this might not have anything to do with the above problem as the problem is happening during the handshake phase but this might give some insight if still we have problem after handshake.
-
Trac:
Summary: How is Pars Online blocking Tor? to How is Iran blocking Tor?
Description: Some users reported that the Iranian ISP "Pars Online" is (partially?) blocking Tor.One user looked into it and believes that Tor is identified based on the server_name extension in the TLS client hello. It looks like DPI boxes extract the domain and do a DNS lookup for it. If the domain resolves and the relay/bridge is listening on port 443, the connection passes. Apparently, an omitted server_name or a server_name rewritten to
www.google.compassed the filter.Obfsproxy seems to work.
Some open questions:
- Can we reproduce and verify the existing hypothesis?
- Is this an attempt to only allow HTTPS and no other SSL/TLS-based protocols? Or is it targeting only Tor?
- Can we modify brdgrd to evade the server_name extraction?
- Is this type of block limited to Pars Online?
to
Note that currently it looks like there might be more than just one filtering technique in place. The following was the initial report describing one possible filtering technique and this comment describes another technique.
Some users reported that the Iranian ISP "Pars Online" is (partially?) blocking Tor.
One user looked into it and believes that Tor is identified based on the server_name extension in the TLS client hello. It looks like DPI boxes extract the domain and do a DNS lookup for it. If the domain resolves and the relay/bridge is listening on port 443, the connection passes. Apparently, an omitted server_name or a server_name rewritten to
www.google.compassed the filter.Obfsproxy seems to work.
Some open questions:
- Can we reproduce and verify the existing hypothesis?
- Is this an attempt to only allow HTTPS and no other SSL/TLS-based protocols? Or is it targeting only Tor?
- Can we modify brdgrd to evade the server_name extraction?
- Is this type of block limited to Pars Online?
-
Independent of the above report, which might not even be targeting Tor, there is another filtering technique which seems to affect parts of Iran. It looks like DPI boxes fingerprint information in the TLS client key exchange which is sent after the TLS server hello. The client key exchange never makes it to the bridge. It is silently dropped somewhere along the path. The following flow diagram illustrates this behavior:
|Time | .ir Client Relay | | | | |0.060 | 12345 > 443 [SYN] |TCP: 12345 > 443 [SYN] | |(12345) ------------------> (443) | |0.322 | 443 > 12345 [SYN, ACK] |TCP: 443 > 12345 [SYN, ACK] | |(12345) <------------------ (443) | |0.322 | 12345 > 443 [ACK] |TCP: 12345 > 443 [ACK] | |(12345) ------------------> (443) | |0.374 | Client Hello |TLSv1: Client Hello | |(12345) ------------------> (443) | |0.660 | Server Hello, Certi |TLSv1: Server Hello, Certificate, Server Key Exchange, Server Hello Done | |(12345) <------------------ (443) | |0.676 | Client Key Exchange |TLSv1: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message | |(12345) ------------------> (443) | |3.201 | [TCP Retransmission |TLSv1: [TCP Retransmission] Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message | |(12345) ------------------> (443) | |8.357 | [TCP Retransmission |TLSv1: [TCP Retransmission] Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message | |(12345) ------------------> (443) | |18.746 | [TCP Retransmission |TLSv1: [TCP Retransmission] Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message | |(12345) ------------------> (443) | |29.135 | [TCP Retransmission |TLSv1: [TCP Retransmission] Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message | |(12345) ------------------> (443) |In a new packet dump, we have even seen obviously spoofed RST segments being sent in addition to the silent packet drop. After the fingerprint is detected, several RST segments are sent to both, the client and the bridge. However, the RST segments are not well-formed and as a result not accepted by the client's and the bridge's TCP stack. Perhaps somebody is experimenting with out-of-band boxes.
-
Trac:
Description: Note that currently it looks like there might be more than just one filtering technique in place. The following was the initial report describing one possible filtering technique and this comment describes another technique.
Some users reported that the Iranian ISP "Pars Online" is (partially?) blocking Tor.
One user looked into it and believes that Tor is identified based on the server_name extension in the TLS client hello. It looks like DPI boxes extract the domain and do a DNS lookup for it. If the domain resolves and the relay/bridge is listening on port 443, the connection passes. Apparently, an omitted server_name or a server_name rewritten to
www.google.compassed the filter.Obfsproxy seems to work.
Some open questions:
- Can we reproduce and verify the existing hypothesis?
- Is this an attempt to only allow HTTPS and no other SSL/TLS-based protocols? Or is it targeting only Tor?
- Can we modify brdgrd to evade the server_name extraction?
- Is this type of block limited to Pars Online?
to
Note that currently it looks like there might be more than just one filtering technique in place. The following was the initial report describing one possible filtering technique and this comment describes another technique.
Some users reported that the Iranian ISP "Pars Online" is (partially?) blocking Tor.
One user looked into it and believes that Tor is identified based on the server_name extension in the TLS client hello. It looks like DPI boxes extract the domain and do a DNS lookup for it. If the domain resolves and the relay/bridge is listening on port 443, the connection passes. Apparently, an omitted server_name or a server_name rewritten to
www.google.compassed the filter.Obfsproxy seems to work.
Some open questions:
- Can we reproduce and verify the existing hypothesis?
- Is this an attempt to only allow HTTPS and no other SSL/TLS-based protocols? Or is it targeting only Tor?
- Can we modify brdgrd to evade the server_name extraction?
- Is this type of block limited to Pars Online?
-
Interestingly, Tor gained ~20,000 Iranian users and then lost them again within the course of last week. No real political or social reason for this, as opposed to when Google was blocked in October. I am more inclined to think that there is really something going on here, despite having had people check on at least four ISPs.
Trac:
Username: cda -
Trac:
Username: Tus
Cc: runa, vmon to runa, vmon, mjackstone1@gmail.com -
Trac:
Username: Tus
Cc: runa, vmon, mjackstone1@gmail.com to runa, vmon -
FYI, I can now reproduce this after hearing of other cases, however, GNU TLS seems to be the common client stepping on the DPI rule. It seems as though there is a whitelisting occurring on the SNI (for possibly non-Browser connectivity). For example, git to Github is failing, despite the fact that one can browse to Github fine. Sending a Google-related SNI to Github negotiates properly up to the mismatch names, but the reciprocal of Github/arbitrary SNIs to Google fails. Something at the international gateway is sending a FIN/ACK and then a RST. So, something to keep in mind.
Trac:
Username: cda
