[tor-bugs] #30716 [Circumvention/Obfs4]: Improve the obfs4 obfuscation protocol

[Tor Bug Tracker & Wiki]

#30716: Improve the obfs4 obfuscation protocol
-------------------------------------------------+-------------------------
 Reporter:  phw                                  |          Owner:  phw
     Type:  task                                 |         Status:
                                                 |  assigned
 Priority:  High                                 |      Milestone:
Component:  Circumvention/Obfs4                  |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  sponsor28, anti-censorship-roadmap-  |  Actual Points:
  october                                        |
Parent ID:                                       |         Points:  20
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor28-must
-------------------------------------------------+-------------------------

Comment (by phw):

 Here's a prototype of the code I've been working on:
 https://dip.torproject.org/phw/obfs4/tree/feature/30716

 It improves obfs4 by giving it the ability to send dummy traffic at any
 time. In the background, the code determines ''when'' it’s time to send
 dummy traffic and ''how much'' should be sent – both values are sampled
 from a Poisson distribution. The arguments to these two distributions are
 (for now) derived from an obfs4 server's public key, so each obfs4 server
 has its own, unique flow signature.

 The idea is that it should be difficult for an adversary to train a single
 classifier that can detect all obfs4 servers. The adversary should instead
 have to train a classifier for each obfs4 server out there. We expect our
 obfs4 evaluation to 1) show what features traffic classifiers rely on and
 2) how to fine-tune the parameters for our flow shaping algorithm.

 So far, I implemented the flow shaping code as a `net.Conn` wrapper in the
 obfs4 client for the following reasons:
 * **Simplicity**: By having only the client keep track of when it’s time
 to inject padding, we keep the implementation simple and make it easy to
 reason about our approach. Note that our obfs4 evaluation may suggest that
 this approach is insufficient, so we should be open to the possibility of
 making the client and server cooperate on flow shaping.
 * **Deployment speed**: Clients can update more rapidly than servers
 because of Tor Browser's auto-update feature.
 * **Backwards-compatibility**: By having the client do all of the flow
 shaping, there is no need for client-server coordination, which means that
 we don’t need to modify the obfs4 protocol. We can therefore update Tor
 Browser with our obfs4 improvements and benefit from these improvements
 without requiring existing obfs4 bridges to update.
 * **Established design**: Other projects
 [https://lists.torproject.org/pipermail/tor-dev/2015-September/009526.html
 have been stacking net.Conn connections on top of each other], hopefully
 making our design more useful for other projects.

 Note that this is work-in-progress and not ready to be used. Several
 questions remain:
 * How well does our flow obfuscator fend off protocol classifiers?
 * How should we choose the arguments to our flow obfuscator?
 * Should we incorporate additional features like a heartbeat? The
 prototype starts a heartbeat with probability 1/5.
 * Should we turn off flow obfuscation after a certain number of seconds
 have passed, or a certain number of bytes/packets have been transferred?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30716#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online