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. >
0x9FC527CC.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
