[guardian-dev] Obfsproxy question

Nathan of Guardian nathan at guardianproject.info
Thu Sep 28 13:27:18 EDT 2017

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:


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:  guardian-dev-unsubscribe at lists.mayfirst.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20170928/ed0d85bb/attachment.html>

More information about the guardian-dev mailing list