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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:
  august                                         |
Parent ID:                                       |         Points:  20
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor28-must
-------------------------------------------------+-------------------------

Comment (by cohosh):

 Nice! Thanks for sharing the update on this!

 I have a few questions and comments about the website fingerprinting
 approach. The observation that these two problems have some overlap is a
 good one, but it's also worth noting that it's not necessarily the case
 that implementing website fingerprinting defences will be strictly better
 for a pluggable transport from an obfuscation point of view.

 The main goal for a website fingerprinting defence is to prevent an
 attacker from learning which site you're visiting, not from learning that
 you are using Tor or even that you are using a website fingerprinting
 defence. And while the website fingerprinting portion is good to have, I
 think the current understanding of website fingerprinting of Tor traffic
 is that it makes more sense to apply to Onion Services at the moment and
 isn't urgent for the rest of Tor traffic yet? This is also being actively
 worked on I believe. Of course PTs don't have to only be used with Tor and
 this would make them better if used for other anti-censorship tools.

 > - We need to build an evaluation framework to understand what works and
 what doesn't.

 So my concern here is that even though the packet breaking is
 probabilistic (and eventually variable, etc.), can we do it without adding
 a fingerprintable feature to the obfuscation traffic? I suppose this is
 related to the "long tail" argument that we have, where hopefully by
 making the sharknado traffic look less and less like any regular thing,
 we're increasing the uncertainty a censor would have in blocking it.

 And it brings us to your bullet point above. It would be an interesting
 research question perhaps to take a look at existing website
 fingerprinting work and see how identifiable the defences are as they are
 implemented in those works given that the adversary knows the client is
 using Tor.

 > - We should find a way to make obfs4's packet sequences server-specific
 by incorporating the server's shared secret into the sequence generation
 process, just like it's done for packet lengths and inter-arrival times.

 Was the purpose of this to maintain some consistency for censors who are
 observing all traffic to a specific bridge IP address (which might make it
 less suspicious)? Or to try to introduce some variability for different
 obfs bridges in order to add to the confusion?

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs