[tor-dev] Projects to combat/defeat data correlation

[Roger Dingledine]

On Mon, Jan 20, 2014 at 05:30:27PM +0100, Philipp Winter wrote:
> On Sat, Jan 18, 2014 at 01:40:43AM +0000, Matthew Finkel wrote:
> > obfs3 is supposed to be fairly difficult to detect because entropy
> > estimation is seemingly more difficult than typically assumed,
> > and thus far from what has been seen in practice this seems to be true.
> 
> There's a recent paper which covers that topic [1].  While entropy estimation
> is certainly more expensive than, say, counting packet sizes, it's probably not
> out of reach for well-equipped boxes.

I think (we should expect that) entropy detection is one of the standard
tools in the DPI toolkit.

obfs3 isn't meant to be secure "because nobody can tell there's a lot of
entropy". It's meant to drive up the risk of false positives -- if you
cut all flows that have a lot of entropy, what else do you cut besides
obfs2 and obfs3? And even if you're convinced it's a worthwhile risk now,
are you convinced the background traffic won't change in the future?

That's why pairing obfs3 with something that modifies packet volume
(and maybe timing) is important -- otherwise more complex DPI rulesets
can look not just for entropy, but also for underlying hints that it's
the Tor protocol underneath, and then reduce their false positive rates.

It also explains why the most effective attacks against obfs2 and obfs3
involve detecting that it "might" be obfs traffic, and then doing some
follow-up checking to get more confidence.

--Roger