Combine traffic obfuscation with address diversity of flash proxy
|Reported by:||karsten||Owned by:||asn|
|Severity:||Keywords:||SponsorF20131101 flashproxy fog|
|Cc:||dcf, nickm, asn, griffinboyce@…, karsten, arlo@…||Actual Points:|
(Quoting text written by David Fifield for this ticket description.)
Find out what current DPI capabilities are with respect to WebSocket, at least through product literature.
Find out what existing, popular, WebSocket applications are used (chat, video, games?) that will be collateral damage to block. Write a short report on 1) how common they are, and 2) what their traffic looks like.
Implement a transport with an obfs2 stream transported over WebSocket.
We can imagine a new "obfs2-in-websocket" transport, but it might be a better design to allow chaining of proxies that don't necessarily have to know about one another. So you might have something like this on the client:
ClientTransportPlugin websocket socks4 127.0.0.1:9001 ClientTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --managed Bridge obfs2|websocket 0.0.1.0:1
On the server:
ServerTransportPlugin websocket proxy 127.0.0.1:9901 ServerTransportPlugin obfs2 exec /usr/local/bin/obfsproxy --managed # And then some new configuration to say that things received on # port 9901 need to be forwarded to the local obfsproxy port. # Port 9901 won't be able to be used for plain websocket # connections, and I guess this will have to be reflected in the # descriptor somewhere.
A client tor can probably managed these chained proxies using SOCKS-in-SOCKS. There's a brief note on chaining proxies here: https://trac.torproject.org/projects/tor/ticket/2841#comment:12
See what other obfuscation possibilities exist. I don't think that TLS-wrapped WebSockets work for us (http://archives.seul.org/or/talk/Oct-2012/msg00190.html), but I haven't thought about it exhaustively. Replacing WebSocket with HTTP requests (the flash proxy POSTs bodies to both the client and the relay, and receives response bodies) would likely work, and would allow fuller control of the payloads (whereas with WebSocket we cannot escape the WebSocket framing). We gave up on using Flash, but Flash sockets allow us to control exactly what goes on the wire, except for an initial cross-domain request.
|#9349||flashproxy facilitator: Allow clients to specify transports||dcf|
Change History (47)
comment:23 in reply to: ↑ 22 Changed 4 years ago by dcf
- Status changed from needs_review to needs_revision
comment:46 Changed 3 years ago by infinity0
- Resolution set to fixed
- Status changed from needs_revision to closed