Opened 3 years ago

Last modified 19 months ago

#4185 new defect

Bridge easily detected by GFW

Reported by: hrimfaxi Owned by:
Priority: normal Milestone: Tor: unspecified
Component: Tor Version: Tor: 0.2.3.5-alpha
Keywords: blocking needs-proposal tor-bridge Cc: asn, runa, rransom, nickm, twilde, phobos, ln5, naif, denver.root@…, eyv@…
Actual Points: Parent ID:
Points:

Description

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?

Child Tickets

TicketSummaryOwner
#4744GFW probes based on Tor's SSL cipher listnickm

Change History (33)

comment:1 Changed 3 years ago by phobos

Can you try walking through these steps, https://trac.torproject.org/projects/tor/wiki/doc/BlockingDiagnostics, and send us the resulting data captures?

comment:2 Changed 3 years ago by mikeperry

  • Cc asn runa rransom nickm added

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.

comment:3 follow-up: Changed 3 years ago by 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.

comment:4 in reply to: ↑ 3 Changed 3 years ago by mikeperry

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.

comment:5 Changed 3 years ago by mikeperry

  • Cc twilde added

comment:6 Changed 3 years ago by aagbsn

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:

  1. create a list of IPs that have connected to Tor or anything else

that wound up in the GFW

  1. actively monitor those IPs and actively connect to destinations.
  2. block anything that doesn't look like a webpage/looks like a Tor bridge.

Some possible counter-attacks/tests

  1. block IPs other than hrimfaxi's, see if the bridge still gets blocked
  2. 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

comment:7 follow-up: Changed 2 years ago by phobos

There is another user report from China where connecting to a new, unpublished bridge fails. I've pointed them at this ticket.

comment:8 Changed 2 years ago by phobos

  • Cc phobos added

comment:9 Changed 2 years ago by asn

This ticket is not very helpful... since it's basically analyzing a private .pcap.

AFAIK bridges don't work in China atm, and will continue to do so till we deploy pluggable transports and/or scanning resistance stuff.

comment:10 Changed 2 years ago by ln5

  • Cc ln5 added

comment:11 follow-up: Changed 2 years ago by asn

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 gets merged, and we make some sort of bundle including obfsproxy with obfs2.

comment:12 in reply to: ↑ 7 ; follow-up: Changed 2 years ago by 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?)

comment:13 in reply to: ↑ 12 Changed 2 years ago by phobos

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.

comment:14 Changed 2 years ago by phobos

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.

comment:15 in reply to: ↑ 11 ; follow-up: Changed 2 years ago by arma

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.

comment:16 in reply to: ↑ 15 Changed 2 years ago by arma

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 may be helpful on this step.

comment:17 Changed 2 years ago by quick-dudley

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.

comment:18 Changed 2 years ago by asn

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.

https://gitorious.org/hot_pot

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

comment:19 Changed 2 years ago by nickm

  • Milestone set to Tor: unspecified

comment:20 Changed 2 years ago by nickm

  • Keywords blocking added

comment:21 Changed 2 years ago by asn

See https://gist.github.com/da3c7a9af01d74cd7de7 for some draft notes on GFW operation, and see #4744 for a plausible cause of GFW Tor probing.

comment:22 Changed 2 years ago by arma

comment:23 Changed 2 years ago by naif

  • Cc naif added

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?

comment:24 Changed 2 years ago by denverroot

  • Cc denver.root@… added

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:

  1. 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.
  2. 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...

comment:25 Changed 2 years ago by naif

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?

comment:26 Changed 2 years ago by denverroot

Well, even if the generation of those isn't predictable, a simple DNS lookup will reveal them as bogus, yes?

comment:27 Changed 2 years ago by asn

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

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

[2]:
http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html#Windows

comment:28 Changed 2 years ago by OlgieD

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.

comment:29 Changed 2 years ago by eyv

  • Cc eyv@… added

comment:30 Changed 23 months ago by somejerk

Think Port Knocking Would Solve This?

comment:31 Changed 19 months ago by nickm

  • Keywords needs-proposal added

comment:32 Changed 19 months ago by nickm

  • Keywords tor-bridge added

comment:33 Changed 19 months ago by nickm

  • Component changed from Tor Bridge to Tor
Note: See TracTickets for help on using tickets.