Delivery-Date: Sun, 04 Jan 2015 13:10:54 -0500
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.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,URIBL_BLOCKED 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 091161E02B4
	for <archiver@seul.org>; Sun,  4 Jan 2015 13:10:53 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 433BE33022;
	Sun,  4 Jan 2015 18:10:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id B18EF33021
 for <tor-talk@lists.torproject.org>; Sun,  4 Jan 2015 18:10:46 +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 HMLv7KmmAIov for <tor-talk@lists.torproject.org>;
 Sun,  4 Jan 2015 18:10:46 +0000 (UTC)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com
 [IPv6:2607:f8b0:4001:c05::234])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 873363300B
 for <tor-talk@lists.torproject.org>; Sun,  4 Jan 2015 18:10:46 +0000 (UTC)
Received: by mail-ig0-f180.google.com with SMTP id h15so1523435igd.1
 for <tor-talk@lists.torproject.org>; Sun, 04 Jan 2015 10:10:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=port.ac.uk; s=google-20130730;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc:content-type;
 bh=cKkfJx9CvYZ0C0TEnK3gTs/+Qhdio1AsDeGUg/l0HVE=;
 b=f1SigjMHxvcK+b6+/Vlnu/sWZvyO1yn4gEUwfMfKSYwso2091NtMWW7jnSodPz/3sU
 en9WkaMGIVlq4ryf8UvWGiPTBR7lnf/0dWQgcFrEUz553vWAPfoByB9UUImVX6bcYpU7
 /jJpxQIoIZUdydi7tdSSYoDoh7dWsqy1T7kgI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc:content-type;
 bh=cKkfJx9CvYZ0C0TEnK3gTs/+Qhdio1AsDeGUg/l0HVE=;
 b=dKVuu9NdjxKk9uZZRLNCdLVPCjtVhfLKQXM6pJkWoHLFzqDa/hC+ruh2Q+CJazwBNW
 CGg1Kp+m2UZ85ZtF9Q628Z+nzYJ/BQ+QV5EUbuxR43rIVfo969qeAaXCQtk7Npq3+J5K
 ENA2dOlSWcmsb8J2bNaz29MrYRAygCAKcC3FWpg/RAIKTjAX6DULPV5Qlj9kYfEGUj45
 a2QXf0T+r625LF+yasOIM6qXySsG25/P/PNEOGvGH4iR87vS/Ro+Qq6OeJ3g4Y7ElEFF
 QiX0g5Q3RWvsSSuZHL2i6HWK3Aq38u87mCJpjJxM6JvFwVTIQx4uu7I5zGrrbA4Cow1M
 0CHA==
X-Gm-Message-State: ALoCoQnNIc58wpeXf1l/zgScVWM/AAV+cZzovlFbHYdn1lzkFQZSFG1r2kE+9Xsz/KMRIO64Zdhs
X-Received: by 10.42.12.147 with SMTP id y19mr64703157icy.80.1420395044112;
 Sun, 04 Jan 2015 10:10:44 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.73.97 with HTTP; Sun, 4 Jan 2015 10:10:23 -0800 (PST)
In-Reply-To: <20150104174334.GA17253@lo.psyced.org>
References: <CAOXPy3wfGZbx5xiyAc3xg98HO4FzOBRYWhdzekZe9sFoS1inzw@mail.gmail.com>
 <20150104174334.GA17253@lo.psyced.org>
From: Gareth Owen <gareth.owen@port.ac.uk>
Date: Sun, 4 Jan 2015 18:10:23 +0000
Message-ID: <CAOXPy3zq-RcX6ox0-Y60FHZjYf58-cibgHYLT6YR6i4-BDC80g@mail.gmail.com>
To: carlo von lynX <lynX@time.to.get.psyced.org>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: tor-talk@lists.torproject.org
Subject: Re: [tor-talk] Shaping Tor's traffic
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>

Hi

I know you weren't looking for me to reply necessarily but let me clarify.
In those slides I was principally talking about non-global adversaries -
e.g. you or me deploying an attack.  With global adversaries they have a
handful more options - namely you don't need to own the guard node if you
can monitor/delay traffic to and from it.

Sorry if it wasn't clear.

Best
Gareth

On 4 January 2015 at 17:43, carlo von lynX <lynX@time.to.get.psyced.org>
wrote:

> On Mon, Nov 17, 2014 at 09:46:37PM +0000, Gareth Owen wrote:
> > Just to let you know, I am also giving a talk at 31c3 on Tor, but my talk
> > is focussing on a research project we did on the Tor HS DHT. I was also
> > planning to talk a little about the Tor Research Framework and an
> > accessible overview of correlation attacks - if time permits.
>
> Excuse me picking up a very old mail, but the question I have
> may (a) be of general interest and (b) possibly be answered by
> someone else but Gareth Owen, the presenter.
>
> There was just one slide at the end of the talk where it occured
> to me that my understanding of Tor felt in disagreement with the
> presenter's.
>
> The slide states that "Traffic confirmation attacks are MUCH
> more powerful" which makes sense to me, but then Gareth says
> that it would take a user to bump into a "dodgy guard relay"
> run by the same attacker that also runs the hidden service
> in order to de-anonymize a user accessing that hidden service.
> Gareth follows up saying you can de-anonymize a fraction of
> hidden service users that way.
>
> Later Gareth says "As the attacker you need to control the
> hidden service's guard node to do these traffic correlation
> attacks."
>
> :From my understanding it isn't necessary to *control* any
> of the guard nodes, it is fully sufficient to be able to
> measure or shape the patterns of traffic moving between
> the guard node and the calling user or the hidden service
> respectively. So essentially any surveillance infrastructure
> monitoring intercontinental traffic may be able to detect
> or shape such traffic if the guard nodes happen to not be
> network topologically close to their respective users.
>
> The only protection I see against that would be if either
> the user is generating plenty of other traffic between her
> node and the guard node while accessing the hidden service,
> or if the hidden service is so popular, it is being talked
> to by several circuits coming from the same guard. And how
> much of a protection that can be would be subject to research.
> To me it sounds like it would just take more time to correlate.
>
> So, from the perspective of a global active adversary doing
> traffic shaping, the general procedure to me sounds like this:
>
> 1. you run confirmation attacks long enough until you have
>    singled out the IP address of the not so hidden service;
> 2. you run heavy weaponry against its guard nodes in order
>    to get control over the software, allowing you to start
>    distinguishing individual circuit activity patterns
>    (this step would only be necessary if the targeted hidden
>    service is very popular);
> 3. you pick out specific tor users and shape their traffic
>    entering their entry nodes to see if those patterns pop
>    out on the way to the hidden service - or other way
>    around, you shape the traffic going back to the user.
>
> Is there anything wrong with my assumptions, or is Gareth
> right that it takes p0wnage of *both* guards in order to
> de-anonymize people? Or is the truth somewhere in-between,
> in the sense that we don't know how well shaping attacks work?
>
> I also wonder, if you're a really good global active attacker,
> you should be able to spot the traffic you shaped anytime it
> crosses your surveillance infrastructure again... so you should
> have a plausible chance of figuring out which websites a user is
> looking up.
>
> I understand the Tor network fluctuates a lot concerning latency
> and throughput, so the attacker would have to do quite aggressive
> shaping, buffering not so little amounts of data, sending specific
> amounts of bytes then introducing pauses of significant duration.
>
> But I'm just theorizing, and maybe Tor has some provisions to
> protect against traffic shaping that I am not aware of. That
> would explain Gareth' statement. I just grepped through a year
> of mailing lists and didn't find traffic shaping discussed much
> at all. Maybe "shap" wasn't the suitable search expression.
>
>
> --
>             http://youbroketheinternet.org
>  ircs://psyced.org/youbroketheinternet
>



-- 
Dr Gareth Owen
Senior Lecturer
Forensic Computing Course Leader
School of Computing, University of Portsmouth

*Office:* BK1.25
*Tel:* +44 (0)2392 84 (6423)
*Web*: ghowen.me
-- 
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

