#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
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
