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 (moved) and proposal 198 influence this.
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?
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.
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).
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.
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.
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.
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?
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.