Delivery-Date: Fri, 18 Mar 2016 23:40:57 -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 [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 463D31E0BEA;
	Fri, 18 Mar 2016 23:40:55 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id D00AD393C6;
	Sat, 19 Mar 2016 03:40:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 1D402392EB
 for <tor-talk@lists.torproject.org>; Sat, 19 Mar 2016 03:40:47 +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 2nGAieT6HiHm for <tor-talk@lists.torproject.org>;
 Sat, 19 Mar 2016 03:40:47 +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 0135038885
 for <tor-talk@lists.torproject.org>; Sat, 19 Mar 2016 03:40:46 +0000 (UTC)
Received: by khazad-dum.seul.org (Postfix, from userid 501)
 id 2984D1E0BEA; Fri, 18 Mar 2016 23:40:44 -0400 (EDT)
Date: Fri, 18 Mar 2016 23:40:44 -0400
From: Roger Dingledine <arma@mit.edu>
To: tor-talk@lists.torproject.org
Message-ID: <20160319034044.GQ8732@moria.seul.org>
References: <nci43k$3ee$1@ger.gmane.org>
 <CAJVRA1SOk_FBO7wXi_tHbFzfPdG21KK5M++45iGcv9tJ8uRs3A@mail.gmail.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAJVRA1SOk_FBO7wXi_tHbFzfPdG21KK5M++45iGcv9tJ8uRs3A@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Subject: Re: [tor-talk] Traffic shaping attack
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 Sat, Mar 19, 2016 at 04:02:53AM +0100, coderman wrote:
> On 3/19/16, Oskar Wendel <o.wendel@wp.pl> wrote:
> >...
> > Let's set up a service in a way that it will modulate the traffic, so the
> > download would look like:
> > [ some distinct signaling here...]
> 
> yes; it's a traffic confirmation attack, and by interrupting the flow
> you confirm that the endpoints in question are involved in that flow.

Right. This general idea of a traffic confirmation attack is an issue
to consider for any low-latency system.

One of the questions to ask is how many points you need to watch in order
to be in a position to launch the attack. This is where Tor fares better
than centralized approaches like VPNs or single-hop proxies, and it's
Tor's best line of defense here.

Another question to ask is whether there will be false positives in the
statistics, i.e. how often your analysis says "yes, match" when actually
it's mistaken. In your scenario, the adversary is doing an active attack
on the traffic, so while I think it's legitimate to speculate about
how false positive rates maybe get high when you're looking at many
Tor flows across many relays (the NSA scenario -- and we even have a
document from an NSA analyst being frustrated by the false positives),
I think it's fair to say that if you generate the signals clearly enough,
false positives will be much less of a worry.

The third question you might ask is: can I inject these signals in a
way that they're still recognizable to me, but observers don't realize
that anything weird is going on with the traffic? That is, can I do
this active traffic modulation attack but still be undetectable? For
that topic, check out these papers:
http://freehaven.net/anonbib/#ndss09-rainbow
http://freehaven.net/anonbib/#ndss11-swirl
http://freehaven.net/anonbib/#pets13-flow-fingerprints

--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

