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