OBFS-series PT issues

[Sam Troper]

Hi all,

Myself, Philipp Winter, and a few others are working on improving OBFS4 by addressing some known issues.

Philipp has added the ability for OBFS to send dummy traffic at any time. (see https://trac.torproject.org/projects/tor/ticket/30716)

I am using his implementation and adding an "entropy obfuscator" which will set an entropy level per OBFS server to address the identification of OBFS outlined in this Wang et al. paper: http://pages.cs.wisc.edu/~liangw/pub/ccsfp653-wangA.pdf

That should be completed in the next few days. We plan to try to identify further issues, but if anyone has identified issues in OBFS that could be addressed we could get started sooner. So, please let us know if there is anything you may have identified in your time working on OBFS or other traffic obfuscation.

Best regards & thanks,

Sam

[Dr. Brandon Wiley]

Very cool work, Sam!

As it won't be compatible with existing obfs4 servers, will this new transport have a new name? Transport trivia: obfs4 was based on scramblesuit, not obfs2 (or obfs3). So while obfs5 is a name that might come to mind, there are additional options. It would be great to have a name which is easy to pronounce and to translate into other languages.

What method are you using for entropy obfuscation? I've written two transports with entropy obfuscation in the past. Dust uses reverse Huffman coding and Protean uses arithmetic coding. I'd love to hear what you decided to use!

Are you incorporating this work into obfs4proxy? There are two other implementations of obfs4 as well. The obfs4 transport in shapeshifter-transports (https://github.com/OperatorFoundation/shapeshifter-transports) and Wisp, which is a Swift implementation compatible with existing obfs4 servers (https://github.com/OperatorFoundation/Shapeshifter-Swift-Transports). If there is any interest in having this new transport used beyond Tor servers, I'd love to help get it into these other transport distribution platforms. In particular, newer versions of OpenVPN should be supporting transports soon and it would be cool to get this new transport wrapped up as an OpenVPN plugin. Let me know if you're interested!

As far as other ideas for useful features for your new transport, we've done testing of the effectiveness of various attacks against obfs4 using Adversary Lab. I won't share the full details here publicly, but I will say that one known and publicly discussed attack on obfs4 that I think you should pay attention to is the timing of the first response packet. Transports that feature a cryptographic key exchange as part of the connection handshake tend to have a higher latency than other types of protocols. If you could minimize the time between the first packet from the client and the first packet from the server (or make it configurable), then this would be a great addition to your new transport. Let me know if you'd be interested in an Adversary Lab analysis of your new transport once it's done.

Best of luck on your new transport, and please let me know if there's anything I can do to help!

--
You received this message because you are subscribed to the Google Groups "Network Traffic Obfuscation" group.
To unsubscribe from this group and stop receiving emails from it, send an email to traffic-obf...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/traffic-obf/36a90ce9-0b91-4ab1-8ed8-fc58c9f7207a%40googlegroups.com.