Potential TLS-over-DTLS blocking in China

[nametoolong]

I run a WebRTC-based proxying tool. I observed a very unusual blocking behavior since two weeks ago. To be precise,

• The DataChannel can always be negotiated without interference.
• The first round-trip after connection establishment is crucial.
• If the first request is a short preamble or a DNS request, no blocking will be seen afterwards (even when blatantly showing a TLS-in-DTLS signature).
• If the first request has obvious TLS-in-DTLS length characteristics (ClientHello+SACK+ServerHello), subsequent large packets (anything more than 200 bytes long, but exact measurements vary; I am reluctant to perform further tests on this for fear of guilty by association) will be dropped. The packet dropping might occasionally be lifted and restored in a short time, most likely to test if the DTLS association is worth unblocking.
• If the first request shows some KCP-like characteristics (e.g. quick retransmission in succession), subsequent packets will be throttled (around 50% packet loss) and large packets still dropped. The lift-and-restore behavior also exists.
• In no case will complete blocking happen.
• Padding is partly effective. Padding ClientHello to 700 bytes does not work; padding to 1200 bytes works sometimes; padding to more than a MTU is guaranteed to work.
• Desktop browsers are more likely to be blocked compared to mobile browsers. Mobile browsers are still able to make some TLS-in-DTLS connections, but I received zero successful reports on desktop browsers. My guess is DTLS fingerprinting.
• None of the behaviors I described differ based on whether a real browser is used. A simple Go program opening the DataChannel (which merely does the DTLS handshake without making any other request) is blocked with the same pattern of a desktop browser.

It is not clear whether the blocking is related to Snowflake. However, the behavior is rather consistent with klzgrad/naiveproxy#469, showing the censor's intention to make proxies unusable with little collateral damage.

[wkrp]

It is not clear whether the blocking is related to Snowflake. However, the behavior is rather consistent with klzgrad/naiveproxy#469, showing the censor's intention to make proxies unusable with little collateral damage.

Thank you, this is very helpful. If you are easily able to test a Snowflake client, maybe you can try this simple patch that adds padding to the first volley of the client:
snowflake-client-padding-20230528.patch.gz

The easiest way to test is in the command line:

cd snowflake/client
gzip -dc snowflake-client-padding-20230528.patch.gz | git apply
go build
tor -f torrc

I had noticed that bandwidth on the snowflake-02 bridge had decreased since 2023-05-22, though there was no matching decrease in the user count. This could be a symptom of throttling, as you suggest: the same number of users, just going slower. There is nothing really notable on the snowflake-01 bridge though, except for perhaps a slight decrease in the user count.

If we break it down by country, the China users of snowflake-02 has actually slightly increased since 2023-05-22. The dip between 2023-05-12 and 2023-05-15 was #249; i.e., it was blocking of the broker rendezvous channel, not DTLS throttling.

Here's some analysis from March 2023 showing a high rate of DTLS packet loss from China:
https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/40251#note_2887929

[nametoolong]

The patch works for me. Snowflake can connect smoothly. It seems like there is no throttling as both directions can reach a few hundred KiB/s.

Note that my tests are very limited. I did not try to induce high KCP retransmission nor tested with other locations/ISPs/lossy networks. I will report here if I find out more.

[wkrp]

A member of the Tor anti-censorship team did a test from China to try to reproduce the packet loss seen in March and see if the padding patch would help it. The test was inconclusive, though, because the old packet loss could not be reproduced this time. Tests with and without padding had equally low packet loss rates. Meeting notes.

It may have to do with not being able to run tests from the same location as before. @nametoolong, are you still experiencing the DTLS throttling?

It may be a good idea to introduce some traffic shaping of the early DTLS stream into Snowflake, in any case. It will be important not to inadvertently create a new traffic analysis signature. Padding might be added at the server side as well, which would be a quicker mitigation than deploying a lot of new client software.

[nametoolong]

The DTLS throttling still affects me. I firstly observed this type of blocking in CMCC Jiangsu (another coincidence with klzgrad/naiveproxy#469), but it can also be reproduced in several other regions and providers (at least reproduced reliably with one CT Guangzhou home network). And yes, some people never experience this.

I am not particularly confident some padding will suffice to improve Snowflake's user experience, though. Chinese ISPs may afford to throttle all WebRTC traffic 🤷 because throttling of unknown UDP traffic is already commonplace in China.

[sippejw]

Hi @nametoolong, a couple of other researchers and myself have been trying to find evidence of tunneled traffic detection and blocking in deployment. Would you be willing to discuss this further with us? If so, can you reach out to me directly at jackson.sippe@colorado.edu.