[tor-dev] Flashproxy alpha bundles
adrelanos at riseup.net
Thu Dec 13 22:15:02 UTC 2012
> Whether these various "look, no hands" punching tools and tricks can be
> done using only websockets on the remote side is a great question for
> somebody to answer.
By the way, I found it in their design paper.
The fact that clients must not be behind NAT is an impediment to usability.
A NAT traversal mechanism that works within our threat model would be a
benefit. Typical NAT traversal technologies, such as STUN (Session Traversal
Utilities for NAT)  and RTMFP (Real Time Media Flow Protocol) , rely
on a stable third-party server to facilitate the connection, which is
feated by the censor blocking the third party by IP address. (Also we
it is better to avoid informing a third party of each flash proxy
connection if it
can be avoided.) Tricks involving low-level packet manipulation, for
nat , are not available to browser sockets. Ideally, any NAT
will not require both the client and the proxy to know each other’s IP
so that facilitator registration can remain unidirectional. New
WebRTC  may fill this need in the future, if they become
that flash proxies’ use of them does not stand out as unusual.
More information about the tor-dev