UP-01-005 Churn sends plain WebRTC Handshakes

[cure53]

The goal of Churn, uProxy’s obfuscated data channels for WebRTC, is to make it “difficult to detect that WebRTC is in use” and thereby prevent it from getting blocked.

Churn first opens a normal WebRTC connection, then reuses the same UDP connection to send obfuscated traffic. This means that both with and without churn, the first WebRTC handshake on the connection is visible, containing certificates for the common name “WebRTC” in plaintext (tested with Chrome and Wireshark). With an iptables command like this, all WebRTC traffic can be blocked, and therefore also all Churn traffic:

# iptables -A INPUT -m comment --comment "block webrtc" -p udp 
    -m string --hex-string "U|04031306|WebRTC" --algo bm -j DROP

Therefore, it is believed that Churn currently provides no benefits compared to a normal WebRTC connection. A normal WebRTC connection would, after the handshake, consist of DTLS application data packets. However, a Churn connection will switch to non-DTLS packets that look random after a short while. Checking for this condition in MITM devices should be relatively easy because normal DTLS packets will e.g. always start with a value in the range 20-23, which means that the use of Churn (and therefore, the use of uProxy) can be detected and blocked by looking for irregular packets in DTLS traffic.

It is recommended to replace the surrogate plain WebRTC connection with custom code that lets both browsers choose ICE candidates, but only invokes setLocalDescription+createOffer at one peer and setRemoteDescription+createAnswer at the other one to prevent the browsers from actually establishing a connection. Afterwards, the uProxy code will have to try candidates until it has found one according to the ICE spec.

[iislucas]

I think we can avoid the webrtc data in the wire by not creating the initial data channel for the first peer-connection. This may warrant a new flag to peer-connection to avoid initial channel creation and use the ice state instead. Then when webrtc starts for real, it's only obfuscated.

[bemasc]

The DTLS handshake is always needed, but we can change the startup sequence so that all traffic between the peers goes through CHURN. I'm working on it.

[willscott]

Just to confirm, the fingerprintable string mentioned, "U|04031306|WebRTC, is obfuscated by doing this?

[bemasc]

It should be, if CHURN is doing its job.

[bemasc]

Fixed by https://github.com/uProxy/uproxy-networking/pull/163