Bridge easily detected by GFW
I tried to setup a bridge relay in USA and access it from China. But it seems their communication can be detected very soon and got filtered by the GFW.
At first I thought it's because the address of my bridge relay got published and leaked to the GFW staffs. But even I set PublishServerDescriptor to 0 in the torrc of bridge the blockade still occurs.
Every bridge relay I setup can only live 1~10 minutes before they got blocked and were no longer accessible in China, used the telnet utility for confirming that.
When the blockade occurs, not only bridges but also normal relays were blocked.
If I change the bridge port (like from 443 to 444) then it can be connected again before the next blockade occurs after 1~10 minutes.
I tried the both stable 0.2.1.x and alpha (0.2.3.5-alpha) release of tor and they were all vulnerable.
Was it a new attack to block tor traffic?
Trac:
Username: hrimfaxi
Activity
changed milestone to %Tor: unspecified
Can you try walking through these steps, https://trac.torproject.org/projects/tor/wiki/doc/BlockingDiagnostics, and send us the resulting data captures?
I walked through the process with hrimfaxi. Will forward logs+traces to asn, rransom, runa, nickm, and whoever else wants to have a look as soon as I get them.
Interesting Note: that he made a mistake the first time through, and had to create a new bridge on a different port on the same IP. It was unblocked to start, and then got blocked again after use. May have affected the results, but maybe not.
Trac:
Cc: N/A to asn, runa, rransom, nickm-
Replying to mikeperry:
FYI: I just got a private message from a different user that their private bridge is working fine in China. Possibly they are behind a different ISP/GFW segment though.
Scratch this. Just hrimfaxi using a different username and stating the IP his bridge was working before it got blocked.
I took a look at tor_traffic_server.pcap. There's a lot of noise, but I eliminated most of the other traffic by exonerator (https://metrics.torproject.org/exonerator.html). That might not be a good assumption, after all, China could control relays in other countries. But here we go:
Stream 15 (same host as Stream 32) looks like the legitimate client. Stream 44 is not a relay, and the TLSv1 Client Hello handshakes are slightly different: (The client in Stream 15 supports more extensions: ec_points_formats, elliptic_curves) than the client in Stream 44.
wireshark filters: (tcp.stream == 15) || (tcp.stream eq 44) or (ip.addr == *****) it also helps to tell wireshark to decode packets with tcp.dst_port==10000 as SSL.A possible attack:
- create a list of IPs that have connected to Tor or anything else that wound up in the GFW
- actively monitor those IPs and actively connect to destinations.
- block anything that doesn't look like a webpage/looks like a Tor bridge.
Some possible counter-attacks/tests
- block IPs other than hrimfaxi's, see if the bridge still gets blocked
- redirect IPs other than hrimfaxi's to a https webpage, see if the bridge still gets blocked
e.g.
iptables -t nat -I PREROUTING --src $hrimfaxi_ip --dst $bridge_host -p tcp --dport $listening_port -j REDIRECT --to-ports $bridge_port iptables -t nat -I PREROUTING --dst $bridge_host -p tcp --dport $listening_port -j REDIRECT --to-ports $https_service
We know that GFW detects the SSL handshake of bridges and probes them aftewards, effectively blocking unpublished bridges. And they probably also have a list of published and detected bridges who they block on sight.
People can probably use obfsproxy.git with tor.git with success, but that requires too much effort for non-technical people. Next step is when #3472 (moved) gets merged, and we make some sort of bundle including obfsproxy with obfs2.
-
Replying to phobos:
There is another user report from China where connecting to a new, unpublished bridge fails. I've pointed them at this ticket.
Did he specify if it fails when connecting, or if the connection fails after some minutes? (read: do they block on SSL handshake, or do they block upon probing?)
Replying to asn:
Replying to phobos:
There is another user report from China where connecting to a new, unpublished bridge fails. I've pointed them at this ticket.
Did he specify if it fails when connecting, or if the connection fails after some minutes? (read: do they block on SSL handshake, or do they block upon probing?)
It's unclear if it's on ssl handshake or probing. They have reported that a brand new, unpublished bridge isn't usable within 5 minutes. But these people may be publishing their pcaps for all. This publishing of data is the reason I pointed them at the ticket.
A user from a Catholic relief organization called today to state that nothing is working in China anymore. They used to use Tor, but that stopped working around two months ago. They even ran some unpublished bridges which stopped working about the same time. They switched to ultrasurf and freegate, and stated that stopped working in the past month. VPNs are hit or miss. VPNs based on ssh or ssl tunnels generally are worse than openvpn or pptp so far. They are going to collect some packet traces and get back to me with results.
Replying to asn:
We know that GFW detects the SSL handshake of bridges and probes them aftewards
We do? Where is that documented? Seems to me that we need to do some more investigation before we can say that we know anything.
In particular, if they are doing active probing of some sort, the first questions are 1) what causes the active probing and 2) what do they use to decide it's something they should block?
In the case of 1, if the rumors are true that vanilla ssl handshakes don't trigger a probe, then we should find out exactly what they're DPIing on and fix it. In the case of 2, if the rumors are true that they're "recognizing Tor" somehow, e.g. during or after the handshake, we should find out what they're looking for.
-
Replying to arma:
In the case of 1, if the rumors are true that vanilla ssl handshakes don't trigger a probe, then we should find out exactly what they're DPIing on and fix it.
#4248 (moved) may be helpful on this step.
There's one bridge I can use intermittently from China: it appears to stay unblocked but it isn't running 24/7 (when I have to wait for it: the reported uptime starts at around zero once it manages to log on). It's in Saudi Arabia. It might be an idea for some bridges to require some secret other than an IP address and a port, and to mimic an https server that requires authentication when probed by someone who doesn't have that secret. The problem is: I can't keep the list of servers and ports I connect to secret from GFW, and they can just check them to see if they're tor bridges by connecting to them with their own copy of tor.
Trac:
Username: quick-dudley-
Some stuff that have to do with this ticket, are still in Request For Comments form, and would appreciate some comments:
http://archives.seul.org/or/dev/Nov-2011/msg00041.html http://archives.seul.org/or/dev/Nov-2011/msg00042.html http://archives.seul.org/or/dev/Nov-2011/msg00073.html
The above links specify client authentication schemes for bridges, to counter active probing and MITM scanning.
The above link is a little program I coded yesterday. It's a GFW prober honeypot. Specifically, it's an SSL server with appropriate logging (and with a little more flexibility than s_server(1)).
-
See https://gist.github.com/da3c7a9af01d74cd7de7 for some draft notes on GFW operation, and see #4744 (moved) for a plausible cause of GFW Tor probing.
-
List of prober addresses: https://gist.github.com/4320b75d398f2e1f074d
Checked several IP of them, it seems that most of them are dynamic IP addresses of DSL and PPP running variety of OS, from Windows 2003 with Terminal Service, Linux with Mysql, cheap home router.
Some questions: a) After the SSL negotiation, does the GFW probes also send an HTTP request or just finish the SSL handshake and close it?
b) Does the prober announce a specific/detectable set of SSL/TLS version/ciphers?
c) Does anyone checked actively with OS fingerprinting tools if the "prober's OS" can be recognized?
Trac:
Cc: asn, runa, rransom, nickm, twilde, phobos, ln5 to asn, runa, rransom, nickm, twilde, phobos, ln5, naif-
My mother lives in China, and the symptoms described in this ticket are quite familiar to me. I am a developer in the US, and have been working with her computer from here for quite some time to try and get Tor running, only to be foiled 99% of the time by the GFW. In the last three years of her living in China, I have observed a lot of odd circumstances unfold with her internet access, and some trends lead me to two conclusions:
- Once China sees "suspicious" activity coming from/happening at a particular location, the surveillance and filtering for that location will increase, sometimes dramatically. This typically functions like an on/off switch, and doesn't have much "fade-in" time.
- Although evidence hasn't been conclusive here yet, this is the trend I see: they "forget" about the heightened filtering for a particular location pretty quickly, typically within a couple days. Often, when my mother's traffic has gotten much more interfered with because of whatever she did to trigger it, after her IP Address expires and renews to a new address, all of that filtering will disappear. I would expect them to "follow her" through IP Address expirations/renewals, but that doesn't normally seem to happen.
I don't have a lot of hard data to give you to back these observations up, but have been working with her system through a lot of changes, moves, and situations, and these two things seem to stick out, at least in ways that are of interest here.
I have talked with Andrew(@torproject) about my mom's situation in the past (late September, 2011), and also our willingness to help. I am quite willing to help diagnose things, test bridges and experimental solutions, etc, if that might help with the things outlined in this ticket, which we face regularly, or really if it might help with making Tor more available in any way. Her habits keep her out of any kind of lime-light in China, which I think is helpful when trying out things like this...
Trac:
Username: denverroot
Cc: asn, runa, rransom, nickm, twilde, phobos, ln5, naif to asn, runa, rransom, nickm, twilde, phobos, ln5, naif, denver.root@gmail.com Would it possible that the detection come from some predictable guessing of the Common Name and Certificate Chain?
Connecting via OpenSSL to a Tor Server i see: Certificate chain 0 s:/CN=www.zb42yfn4kbhtd.net i:/CN=www.noyz3wih.com
Are the way those fields get generated guessable by Active Probing and/or passive analysis?
-
Checked several IP of them, it seems that most of them are dynamic IP addresses of DSL and PPP running variety of OS, from Windows 2003 with Terminal Service, Linux with Mysql, cheap home router.
Seems so, indeed. Fucked up, isn't it? It seems like none of their probers is an actual dedicated server probing box...
Some questions: a) After the SSL negotiation, does the GFW probes also send an HTTP request or just finish the SSL handshake and close it?
There are two kinds of probes: 'Garbage probing' and 'Tor probing'.
In 'Garbage probing', the prober connects and spits a "random" blob of data to the host, a la: http://www.nsc.liu.se/~nixon/sshprobes.html
In 'Tor probing', the prober connects, does an SSL handshake, does an SSL renegotiation and then speaks the Tor protocol. Specifically, the Tor probers we managed to capture, build an one-hop circuit and send a BEGIN_DIR cell, like Tor clients are supposed to do. When the bridge replies with its descriptor, the prober hangs up.
b) Does the prober announce a specific/detectable set of SSL/TLS version/ciphers?
The SSL handshakes of probers seem similar to the SSL handshake of Tor clients.
The cipher list (also, see #4744 (moved)) is the same, and they both have the same fake 'server_name' extension. What is different is that probers don't seem to have the ECC TLS extensions, which I think are added automatically by new versions of OpenSSL (still, probers seem to have the RI ciphersuite, which is also added automatically by new versions of OpenSSL).
c) Does anyone checked actively with OS fingerprinting tools if the "prober's OS" can be recognized?
We did some checks. There seems to be a mixture of Windows and Linux machines.
I've noticed that some of the machines had IIS running.
Also, some probers [1] are using a source port that is not in the ephemeral port range of modern OSes (usually higher than TCP port 20000), which hints to Windows XP 2.
Would it possible that the detection come from some predictable guessing of the Common Name and Certificate Chain?
Connecting via OpenSSL to a Tor Server i see: Certificate chain
0 s:/CN=www.zb42yfn4kbhtd.net i:/CN=www.noyz3wih.comAre the way those fields get generated guessable by Active Probing and/or passive analysis?
Sure. Although, it seems like the current probes are caused by the cipher list (see #4744 (moved)). Also, see proposal 179.
[0]: This is an example prober SSL handshake:
TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 139 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 135 Version: TLS 1.0 (0x0301) Random gmt_unix_time: Dec 9, 2011 07:18:12.000000000 CET random_bytes: 2ade076693d5ecf217d0fc3cfb0e6d1c9cb03f81358b2534... Session ID Length: 0 Cipher Suites Length: 58 Cipher Suites (29 suites) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c) Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e) Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002) Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d) Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003) Cipher Suite: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0xfeff) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 36 Extension: server_name Type: server_name (0x0000) Length: 28 Data (28 bytes) Extension: SessionTicket TLS Type: SessionTicket TLS (0x0023) Length: 0 Data (0 bytes)[1]: 2011-12-05 18:26:58.839414 : 218.10.51.83:1629 2011-12-05 18:26:58.839469 | '\xd7s\x10\x05\x95\x86\xe6\x89ok\x07\xd2\x95\xab}\x16\x10\xc4\xc8F\xac|ax\x86d\xc6\x03\x19_=\xd1\x13W\x14\x8dG\x0e;Y.'\xd2\x90\xa3\xab X\xb1w\x97\xe4e\xd8A=\xc7\xd0\xe4S\xc46\xcb\x86\xea9\x9bIz\xe0\xa8\xe7\xb7\x1b\x8c\xa8H\x1aK\xfdl\t\xdf\xa0\xb4\xd3\xcd\xe8r~\xd5\u\xfa\xdb\xab\xad\xf5s'U\x9a\x0e\x0c4\x993|3\xfc\xf8\x1e\x85\xd8\xbd9\xab\n!\x9d\x87vx\xfbp\xd2&\x9c\xc7\x18\xc2\x1c\xb1O\xa6eg\xd8`\x99UX\xb6\xd90s\x12[|\xb2\xf7\x83(\xee~\x17\xc0$\xb2\x87;\xf3"lB\xc7\xd0\xa8\x1f\xaf\xc1s\x07wL\xb6j\xdd\x11e\x8f\x87\xe76u\xe5\xcb5\t};C\xef\\xae1\xa2\xfdX\xc0\xac\x19\xb33\x90\xfe\xe8y[\xf8]\xe9\xfeE\x9es\xa9i'\xb1easT<\xa1\x84]\x9e\xdc\x9c\xcatO\xfc\x04\xcdd\xfb(\xdbY\x91\xd9\x1d/L\xc5\x98\xf1\xf5|Rh\xd0\r\t\xd3i'/\x84p\xa3\xd3l&\xa0\xcf"G*\xf9\xd7\x03\x16\x07\xcdZ\x1e'
-
I'm not going to pretend to know too much about the internals of Tor, so may not be able to contribute much to the actual development, but do know a few things about security and networks. The thought I had, considering the GFW filters all passing traffic, is it possible source and destination are probed for tor signatures, and subsequently blocked if found? That would explain why even new bridges are quickly blocked. I realize there would be a massive amount of streams going in and out of China.
Trac:
Username: OlgieD Trac:
Cc: asn, runa, rransom, nickm, twilde, phobos, ln5, naif, denver.root@gmail.com to asn, runa, rransom, nickm, twilde, phobos, ln5, naif, denver.root@gmail.com, eyv@ksu.edumoved to tpo/core/tor#4185 (closed)
