Opened 6 years ago

Closed 15 months ago

#6045 closed task (fixed)

Ethiopia blocks Tor based on ServerHello

Reported by: asn Owned by:
Priority: Medium Milestone:
Component: Obfuscation/Censorship analysis Version:
Severity: Normal Keywords: dpi censorship block et
Cc: runa, phw, bill-torstuff@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Ethiopia is blocking Tor by DPIing the ServerHello TLS record. We
found out that changing the ciphersuite selected (from the default
TLS1_TXT_DHE_RSA_WITH_AES_256_SHA (0x0039)) bypasses the censorship.

This is a ticket to see how we can handle this issue. We should also
be think about how #4744 and proposal 198 influence this.

The patch we used during tests removes 0x0039 from SERVER_CIPHER_LIST:
https://gitorious.org/mytor/mytor/commit/087de5215cada3320c8494fdc97b87746b45e1cb

A good short-term plan would be to set-up a few patched bridges,
update the blog post, and distribute the patched bridges to anyone who
asks for them.

Child Tickets

Attachments (4)

finalhello-skip.patch (468 bytes) - added by runa 6 years ago.
phunny_packet.bin (937 bytes) - added by asn 6 years ago.
a phunny packet
phunnier_packet.bin (73 bytes) - added by asn 6 years ago.
a phunnier packet
phunniest_packet.bin (33 bytes) - added by asn 6 years ago.
the phunniest packet

Download all attachments as: .zip

Change History (30)

comment:1 Changed 6 years ago by runa

Just to clarify things; the Obfsproxy Tor Browser Bundle would help these users, but we are currently blocked by #5937.

comment:2 Changed 6 years ago by runa

Blog post is up on https://blog.torproject.org/blog/update-censorship-ethiopia - we'll see how fast the bridges are blocked (in Ethiopia, I'm sure China will block them first).

comment:3 Changed 6 years ago by cypherpunks

For actual checking theory about only one condition that trigger DPI, could you ask of someone from Ethiopia do test.

For test purpose you need to use standard modern Firefox and connect to normal validated https site that negotiate exactly the same cipher suite as described (TLS1_TXT_DHE_RSA_WITH_AES_256_SHA)?

Did you ran such test? Did you know such example site? What reported result?

comment:4 in reply to:  3 Changed 6 years ago by runa

Replying to cypherpunks:

For test purpose you need to use standard modern Firefox and connect to normal validated https site that negotiate exactly the same cipher suite as described (TLS1_TXT_DHE_RSA_WITH_AES_256_SHA)?

Sounds like a good idea. The challenge would be finding a website that is (1) HTTPS, (2) blocked in Ethiopia, (3) negotiates TLS1_TXT_DHE_RSA_WITH_AES_256_SHA.

Did you ran such test? Did you know such example site? What reported result?

I ran a test where I asked the user to visit a blocked website, without Tor, and capture the traffic with Wireshark. I don't know if the site he/she visited negotiated the same cipher suite, though. The result was that the user got a message saying the connection had been reset. This is the same message you get if you visit baidu.com and search for a term you know is blocked in China.

comment:5 Changed 6 years ago by runa

It has been suggested we use https://ws.sso.post.ch/ as an example site.

comment:6 Changed 6 years ago by phw

I connected to the web site using Firefox 13 and 0x0039 was selected. I extracted the server hello and did the old hping trick but the packet apparently passed the filters (I got RSTs back).

The TLS version is 1.0 for both server hellos. Feel free to reproduce:
Bridge TLS server hello: http://files.7c0.org/brd-server-hello.bin
Web server TLS server hello: http://files.7c0.org/websrv-server-hello.bin

The biggest difference between those two server hellos is between the extensions.

comment:7 Changed 6 years ago by murble

Cc: bill-torstuff@… added

It seems for the blocking to happen you have to have Hello, Cert, Server Key Exchange and Hello Done in the same packet.

stud (https://github.com/bumptech/stud) configured with a self signed key and the recommended settings is also blocked example (https://www.yuri.org.uk/~murble/tor/0x39serverstud1024.cap) the server hello from https://bu.mp/ also TLS1_TXT_DHE_RSA_WITH_AES_256_SHA is not blocked as it doesn't
all fit in a single packet(?). Normal web servers with non self signed certs do not seem to to fit the above in a single packet.

comment:8 in reply to:  7 Changed 6 years ago by runa

Replying to murble:

It seems for the blocking to happen you have to have Hello, Cert, Server Key Exchange and Hello Done in the same packet.

Confirmed. Your special bridge, which causes the final hello done TLS record to be sent in a separate packet, works fine.

Changed 6 years ago by runa

Attachment: finalhello-skip.patch added

Changed 6 years ago by asn

Attachment: phunny_packet.bin added

a phunny packet

Changed 6 years ago by asn

Attachment: phunnier_packet.bin added

a phunnier packet

Changed 6 years ago by asn

Attachment: phunniest_packet.bin added

the phunniest packet

comment:9 Changed 6 years ago by asn

It seems that packets can't get funnier than the last attached one. Furthermore, their firewall seems to let everything below 75 bytes pass, so you have to pad the attached packet to 75 bytes.

comment:10 Changed 6 years ago by runa

I just got an email from someone in Kazakhstan saying that the normal Tor Browser Bundle with murble's special bridge works; the bridge with the patch that causes the final hello done TLS record to be sent in a separate packet.

comment:11 in reply to:  10 Changed 6 years ago by runa

Replying to runa:

I just got an email from someone in Kazakhstan saying that the normal Tor Browser Bundle with murble's special bridge works; the bridge with the patch that causes the final hello done TLS record to be sent in a separate packet.

Apparently, this was tested and found to be working in Kazakhstan months ago. I'm not sure if the patch made it into a ticket at that point, so documenting it now. Better than nothing, I guess?

comment:12 in reply to:  10 Changed 6 years ago by runa

Replying to runa:

I just got an email from someone in Kazakhstan saying that the normal Tor Browser Bundle with murble's special bridge works; the bridge with the patch that causes the final hello done TLS record to be sent in a separate packet.

The three bridges in https://blog.torproject.org/blog/update-censorship-ethiopia are also working in Kazakhstan. These are bridges with a patch that removes 0x0039 from SERVER_CIPHER_LIST.

comment:13 Changed 6 years ago by runa

We can discuss Kazakhstan in #6140.

comment:14 Changed 6 years ago by runa

Component: Tor BridgeCensorship analysis
Owner: set to runa

comment:15 Changed 6 years ago by runa

Owner: runa deleted
Status: newassigned

comment:16 Changed 6 years ago by runa

asn linked me https://gitorious.org/d0wser/d0wser/blobs/master/d0wser.go when I asked how he created phunny_packet/phunnier_packet/phunniest_packet. I'm sure it'll be useful some other time.

comment:17 Changed 6 years ago by asn

For the record, phunnier_packet and phunniest_packet might be lies. It seems that .et treats packets of size 73 or 75 bytes weirdly (possibly other sizes too). For example:

# hping3 -p 31923 -E /dev/zero -d 72 -A 213.55.83.157
# hping3 -p 31923 -E /dev/zero -d 74 -A 213.55.83.157
# hping3 -p 31923 -E /dev/zero -d 76 -A 213.55.83.157

give RSTs back

but

# hping3 -p 31923 -E /dev/zero -d 73 -A 213.55.83.157
# hping3 -p 443 -E  /dev/zero  -d 75 -A 213.55.85.2

do not give RSTs back.

I'll make a script to see what packet sizes with /dev/zero get dropped.

comment:18 Changed 6 years ago by asn

Here are the fingerprints we know off:

clienthello, 
             from beginning of ClientHello till after record-type.
                 [16 03 01 00 35 02 00]

             version field
                 [03 01]

             session id, cipher suite, and compression method
                 [00 00 39 00]

             renegotiation info
                 [ff 01 00 01 00]
certificate,
             from beginning, till the end of length field
                 [16 03 01 01 cf]
serverkeyexchange,
             from beginning, till the end of length field
                 [16 03 01 01 8d]
serverhellodone,
             from beginning, till the end of length field                
                 [16 03 01 00 04]

comment:19 Changed 6 years ago by phw

It looks like the DPI boxes now also look for the TLS client hello. The server hello continues to be filtered as well. The three bridges published in the blog post are not blacklisted. They just don't get the user's client hello.

comment:20 in reply to:  19 ; Changed 6 years ago by arma

Replying to phw:

It looks like the DPI boxes now also look for the TLS client hello. The server hello continues to be filtered as well. The three bridges published in the blog post are not blacklisted. They just don't get the user's client hello.

True for Tor 0.2.3.17-beta and later as well (on the client-side)?

comment:21 in reply to:  20 Changed 6 years ago by runa

Replying to arma:

Replying to phw:

It looks like the DPI boxes now also look for the TLS client hello. The server hello continues to be filtered as well. The three bridges published in the blog post are not blacklisted. They just don't get the user's client hello.

True for Tor 0.2.3.17-beta and later as well (on the client-side)?

We don't have packages for 0.2.3.17-beta.

comment:22 in reply to:  20 Changed 6 years ago by phw

Replying to arma:

Replying to phw:

It looks like the DPI boxes now also look for the TLS client hello. The server hello continues to be filtered as well. The three bridges published in the blog post are not blacklisted. They just don't get the user's client hello.

True for Tor 0.2.3.17-beta and later as well (on the client-side)?

The TLS client hello as sent by version 0.2.3.17-beta passes the filters, suggesting that the cipher list (of Tor versions < 0.2.3.17-beta) is part of the fingerprint.

comment:23 Changed 6 years ago by runa

Tor 0.2.2.36 + patch for changing the selected ciphersuite + brdgrd currently works in Ethiopia.

comment:24 Changed 6 years ago by phw

The usage statistics are back up again and start to look like the time series before the block.

comment:25 Changed 3 years ago by dcf

Severity: Normal

https://metrics.torproject.org/userstats-relay-country.png
https://metrics.torproject.org/userstats-bridge-country.png

comment:26 Changed 15 months ago by dcf

Keywords: censorship block et added
Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.