iislucas
commented
10 years ago Thanks for the detailed analysis. This highlights that at v1, we're basically stacked against WebRTC as collateral if someone wants to block uProxy.
Using WebRTC as a base for transport, I can see how to remove the DNS requests, obfuscate the DTLS, but the stun-pinging that is part of ICE seems much harder to remove/hide.
w.r.t. STUN servers, we'll need to experiment some with how to make this not look so difference to other P2P tools like skype.
tricky challenges.
The reliance on WebRTC makes the uProxy networking samples, and uProxy in general, follow a very clear traffic pattern sequence, which facilitates traffic identification, blocking and potentially other MiTM attacks.
The following is a high level summary of the predictable traffic pattern:
Weakness 1) Overall, the sequence of steps is consistent and facilitates fingerprinting This allows a censor to combine this with other findings in this document, for additional accuracy, and then block DTLS or even UDP or TCP traffic sent between uProxy peers.
Weakness 2) A DNS request to all ICE servers is made Right after the chrome app is enabled, a DNS request to all ICE servers is made (affects: both copy paste and simple socks sample applications)
In the source code the DNS queries match an ICE server list found in the following files:
Which contain the following:
Potential Issues based on that:
Weakness 3) STUN traffic can be pointed to the wrong servers spoofing DNS replies Using freely available tools, such as dnschef, a censor could spoof DNS replies to invalid IP addresses and block uProxy that way. Weakness 4) The amount of STUN traffic gives away WebRTC is likely in use During packet capture analysis it was found that the amount of STUN traffic sent by uProxy makes it clear that WebRTC is in use. The amount of STUN packets sent by uProxy is similar to various WebRTC demo pages, but significantly greater than, for example, Skype which might just send one STUN packet in a Skype call. For comparison purposes, uProxy (and other WebRTC applications) will send more than one thousand STUN packets in 20 seconds. This weakness alone seems to defeat the purpose of churn obfuscation.
This finding can be summarised by saying that the reliance on WebRTC makes uProxy traffic patterns predictable, and therefore a design weakness that facilitates censorship. While a WebRTC approach is innovative and interesting, uProxy should consider alternative, WebRTC-independent, transport mechanisms in future releases to address this design weakness. This would allow uProxy to recover from situations where WebRTC traffic patterns are blocked by a censor. The Psiphon circumvention system could be a good source of inspiration for this purpose, since it features:
The Psiphon design document provides more detailed implementation insight and might be helpful, as a reference, in future uProxy design improvements.