Just want to point out that there is a "Network Traffic Obfuscation" Google Group with many of the authors of various pluggable transports on it:
https://groups.google.com/forum/#!forum/traffic-obf I think some of the excellent concepts being discussed here have been explored in some other Tor PT's. On 09/28/2017 05:37 AM, Michael Rogers wrote: > Hi Matej, > > This is a really interesting idea. As far as I know, the obfsproxy > protocols don't try to look like HTTP - they just try to look random. > But running an HTTP server on the same port might make it harder for a > censor to classify an obfuscated bridge. > > My first thought was that the bridge could check the first few bytes of > each connection to see if it looked like HTTP or an obfuscated > handshake, and pass the connection to an HTTP server or obfsproxy > accordingly. That would be tricky to implement without allowing the > censor to distinguish the bridge from an ordinary HTTP server by sending > subtly invalid HTTP requests. But a bigger issue is that if we assume > the censor can monitor the bridge's traffic as well as connecting to it > (which we've already assumed if we're using obfuscation), then any > server that accepts HTTP and some unknown protocol on the same port > already looks suspicious. > > Another possibility is to tunnel the obfuscated protocol over HTTP. In > that case the bridge doesn't need to distinguish between HTTP requests > and obfuscated handshakes - all connections go to a standard HTTP > server, which is configured to pass requests for certain URLs to obfsproxy. > > There are various hacks for tunneling interactive protocols over HTTP, > such as using one connection to send data in request bodies and a second > connection to poll for data in response bodies. The officially blessed > solution is websockets. > > The nice thing about all these methods from our point of view is that > people use them to carry a whole range of custom protocols. I'd > speculate that censors see "unknown protocol over websockets" at least > as often as they see "unknown protocol over TCP", because there are more > developers at the HTTP layer. So blocking all such traffic or flagging > it for closer inspection is unappealing. > > You could probably put together a proof-of-concept using the following > pieces: > > * obfs4 on the client and server > * Gorilla websocket library on the client and server, wrapping obfs4 > connections in the websocket protocol > * nginx on the server, serving a real site and reverse proxying > websocket connections to Gorilla > > Bonus points if the real site is a popular forum celebrating patriotism > and religious orthodoxy. ;-) > > Cheers, > Michael > > On 24/09/17 22:38, Matej Kovacic via guardian-dev wrote: >> Hi, >> >> I have a question about Obfsproxy. As I understand, it starts a server >> at TCP/80 port and listens to a traffic, which is masked as HTTP. >> >> My question is - is it possible to run a legitimate HTTP server on port >> 80, so that if someone will connect to the website with web browser, it >> will get a legitimate website. But if someone will connect with >> Obfsproxy, his or her traffic will be redirected to Obfsproxy (and then >> relayed forward). >> >> OpenVPN has a similar feature, called port sharing. It can be configured >> to use TCP/443 port, which is normally used for HTTPS. But if OpenVPN >> detects non-vpn traffic, it will relay traffic to a local port through >> port sharing mechanism. >> >> The result is that when someone connects to OpenVPN with OpenVPN client, >> he will get access to VPN, but if the same person connects to the same >> port and same IP with web browser - it will get legitimate HTTPS traffic. >> >> >> Regards, >> M. >> >> >> >> _______________________________________________ >> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev >> To unsubscribe, email: [email protected]
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
