[tor-dev] "Seeing through Network-Protocol Obfuscation"

[Yawning Angel]

NB: quickly responding before I go to bed.

On Wed, 19 Aug 2015 14:13:03 -0400
Philipp Winter <phw at nymity.ch> wrote:
> <https://kpdyer.com/publications/ccs2015-measurement.pdf>
> 
> They claim that they are able to detect obfs3, obfs4, FTE, and meek
> using entropy analysis and machine learning.

Not surprised for obfs3/4 since they're mounting an entropy attack which
is explicitly outside of the stated threat model for both protocols.

The FTE semantic attack they presented isn't the easiest one I know of
(the GET request as defined by the regex is pathologically malformed).

Haven't looked at the meek portion of the paper.

> I wonder if their dataset allows for such a conclusion.  They use a
> (admittedly, large) set of flow traces gathered at a college campus.
> One of the traces is from 2010.  The Internet was a different place
> back then.  I would also expect college traces to be very different
> from country-level traces.  For example, the latter should contain
> significantly more file sharing, and other traffic that is considered
> inappropriate in a college setting.  Many countries also have popular
> web sites and applications that might be completely missing in their
> data sets.

Dunno.  Others probably have a better idea on what average internet
traffic looks like these days.

> Considering the rate difference between normal and obfuscated traffic,
> the false positive rate in the analysis is significant.  Trained
> classifiers also seem to do badly when classifying traces they weren't
> trained for.  The authors suggest active probing to reduce false
> positives, but don't mention that this doesn't work against obfs4 and
> meek.

Coming up with something better than obfs4/meek would be nice.  At this
point I'm viewing obfs4 as more of a minimum standard than anything
else.

It's worth noting that Dust2 (mostly done but not yet deployed) can
reduce payload entropy to match a target distribution, but will have
issues with protocol whitelist based DPI.

Regards,

-- 
Yawning Angel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150819/20cb914e/attachment.sig>