Delivery-Date: Wed, 01 Jun 2016 02:30:22 -0400
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [138.201.14.202])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id DC8371E0A4F;
	Wed,  1 Jun 2016 02:30:20 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4F825E0F2C;
	Wed,  1 Jun 2016 06:30:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id A05B7E0E9B
 for <tor-talk@lists.torproject.org>; Wed,  1 Jun 2016 06:30:11 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id do-TwkRYR4o6 for <tor-talk@lists.torproject.org>;
 Wed,  1 Jun 2016 06:30:11 +0000 (UTC)
Received: from khazad-dum.seul.org (khazad-dum.csail.mit.edu [128.31.0.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "moria.seul.org", Issuer "moria.seul.org" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 706AFE0E90
 for <tor-talk@lists.torproject.org>; Wed,  1 Jun 2016 06:30:11 +0000 (UTC)
Received: by khazad-dum.seul.org (Postfix, from userid 501)
 id 2CAFF1E0CE7; Wed,  1 Jun 2016 02:30:08 -0400 (EDT)
Date: Wed, 1 Jun 2016 02:30:08 -0400
From: Roger Dingledine <arma@mit.edu>
To: tor-talk@lists.torproject.org
Message-ID: <20160601063008.GC55745@moria.seul.org>
References: <a9dce332-4405-0213-b098-a12665d97dd9@infosecurity.ch>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <a9dce332-4405-0213-b098-a12665d97dd9@infosecurity.ch>
User-Agent: Mutt/1.5.20 (2009-12-10)
Subject: Re: [tor-talk] Ntop nDPI 1.8 with enhanced Tor protocol dissector
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

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

