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 - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
