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

[Aymeric Vitte]

I think this is similar to the problematic highlighted in this thread
https://lists.torproject.org/pipermail/tor-talk/2016-February/040460.html

I read the paper several time but unfortunately could not find what was
new or disruptive

As already stated I don't get that we get stuck on this model of things
tied to a (stupid) domain, verification through the (stupid) domain and
current certificates format, for the global web problematic and future
(ie browsers acting as nodes), and this DPI easy example

But maybe the "at the moment" remark on the above link gives some hope,
the approach could be to link the entities to an entityID (to which we
can add a .thing extension if people like it but it's of no use) that
can be checked via decentralized blocklist/wot/reputation systems/keygen
or combination of them, and then probably this can be used with
letsencrypt, and probably SOP can be enforced the same way with
entityIDs instead of domains, nobody is working on this?


Le 01/06/2016 à 08:30, Roger Dingledine a écrit :
> 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
>

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms