Re: [tor-talk] Ntop nDPI 1.8 with enhanced Tor protocol dissector

[Roger Dingledine <arma@xxxxxxx>]

On Wed, Jun 01, 2016 at 08:05:22AM +0200, Fabio Pietrosanti (naif) - lists wrote:
> the cool ntop project (www.ntop.org) has released it's opensource DPI
> (Deep Packet Inspection) engine with enhanced Tor protocol dissector and
> support http://www.ntop.org/ndpi/released-ndpi-1-8/ .
> 
> They do it by looking at the hostname pattern being used in the TLS
> handshake.
> 
> Community-wise, which is the best way to deal with opensource code that
> facilitate high-performance detection of Tor traffic pattern (likely to
> be used by who would like to profile Tor users) ?
> 
> a. Kindly ask them to re-consider releasing high-performance tools
> available to detect Tor traffic?
> b. Engage in a opensource-code arm-race for detection and anti-detection?
> c. Does nothing?

I think 'a' isn't really an option here, since the detection rule is so
darn easy.

I don't think this is an arms race we can win, at least not without
changing the rules. We could imagine cooler approaches, like hooking
Tor relays into the Let's Encrypt acme engine so they can get legit ssl
certs for each relay. But even then, they would need legit looking names
in the ssl certs -- we could start with dyndns addresses, but eventually
we'd need something better. The rabbit hole goes deep.

Ultimately, this situation is what pluggable transports are for --
either the "look like something" transports that trick the dissector into
knowing what the protocol is but it's wrong, or the "look like nothing"
transports where the dissector considers all the protocols it knows and
comes up empty.

--Roger

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk