[guardian-dev] Obfsproxy question

[Michael Rogers]

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.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20170928/8a23cbb1/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20170928/8a23cbb1/attachment.sig>