Delivery-Date: Sun, 20 Mar 2016 16:23: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,FREEMAIL_FROM,
	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 D61641E0BA5;
	Sun, 20 Mar 2016 16:23:55 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 70F63283A6;
	Sun, 20 Mar 2016 20:23:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 3AC2128386
 for <tor-talk@lists.torproject.org>; Sun, 20 Mar 2016 20:23:44 +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 vYo6qYhoy7iM for <tor-talk@lists.torproject.org>;
 Sun, 20 Mar 2016 20:23:44 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
 (using TLSv1 with cipher AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 073EE2110C
 for <tor-talk@lists.torproject.org>; Sun, 20 Mar 2016 20:23:43 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
 (envelope-from <gno-or-talk-2@m.gmane.org>) id 1ahjsu-0007VH-4F
 for tor-talk@lists.torproject.org; Sun, 20 Mar 2016 21:23:36 +0100
Received: from orion.enn.lu ([94.242.246.24])
 by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
 id 1AlnuQ-0007hv-00
 for <tor-talk@lists.torproject.org>; Sun, 20 Mar 2016 21:23:36 +0100
Received: from o.wendel by orion.enn.lu with local (Gmexim 0.1 (Debian))
 id 1AlnuQ-0007hv-00
 for <tor-talk@lists.torproject.org>; Sun, 20 Mar 2016 21:23:36 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: tor-talk@lists.torproject.org
From: Oskar Wendel <o.wendel@wp.pl>
Date: Sun, 20 Mar 2016 20:23:24 +0000 (UTC)
Lines: 78
Message-ID: <ncn0rr$1jm$1@ger.gmane.org>
References: <nci43k$3ee$1@ger.gmane.org>
 <CAJVRA1SOk_FBO7wXi_tHbFzfPdG21KK5M++45iGcv9tJ8uRs3A@mail.gmail.com>
 <20160319034044.GQ8732@moria.seul.org> <ncjbkj$tfr$1@ger.gmane.org>
 <20160320015647.GR8732@moria.seul.org>
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: orion.enn.lu
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>
MIME-Version: 1.0
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roger Dingledine <arma@mit.edu>:

>> Let's assume that the service is extremely popular, with over 6 terabytes 
>> of traffic each day, and a gigabit port almost constantly saturated.
> 
> This assumed scenario seems extremely unlikely to be happening in
> practice. First because there aren't any relays that are doing 1gbit/s
> of traffic, so no onion service would be able to do that to its guard
> (unless it used many entry guards and spread the load over them, in which
> case it would be screwing its own anonymity). And second because the
> graph at https://metrics.torproject.org/hidserv-rend-relayed-cells.html
> shows there's only something like 1.4gbit/s of onion service traffic in
> the whole network. And third because scalability issues in the current
> design make onion services unable to keep up with the number of users
> that you're describing.

Actually, I blindly told what the site admin published:

"I strongly suspect it's the highest traffic site ever to exist on Tor. 
That's why it's gotten so expensive to run, we use close to 100% of a 
gigabit internet port much of the time, pushing well over 6 TB of traffic 
per day."

I'm not sure if it's true (and from what you say, it seems it's not), but 
the site is very active anyway.

>> This is not a theoretic attack. This is something that has been noticed 
>> on one of illegal sites and I expect many busts around the globe in the 
>> coming weeks.
> 
> More details please?

A couple of users recently noticed this repeatable pattern during 
downloads. From what they told, downloads from this site were always 
smooth and, although the speed have always been fluctuating, it rarely 
stopped completely, and even if it did, it was random. Now, when it 
occurs (because it doesn't occur every time), it occurs perfectly 
repeatedly.

To quote one of the users: "Yes, speed can vary, it is normal and observed 
everywhere in Tor, but it is NOT frequent INTERRUPTS. Normally speed 
changes monotonically, so if interrupt happens, it happens only after the 
speed decreased to just a few KB/s. If speed is perfect, very high, and 
then sudden interrupt happens, it is very warring sign. This may be new 
FBI technique."

> This is not a crazy possibility, but it would be good to know exactly 
> what evidence we have for its being true.

The only evidence I have is how the site started to behave, and what 
the users noticed.

> For example, if somebody noticed "I get a burst of cells from this onion 
> service, then a few seconds of silence, then I get another burst of 
> cells", that's actually a property of our current load balancing 
> algorithm, and not necessarily evidence of an intentional signal being 
> injected into the circuit.

When this load balancing algorithm starts to work? When it is used (to 
balance load between what and what?), and what can be the reason it 
started to behave that way only recently?

- -- 
Oskar Wendel, o.wendel@wp.pl.REMOVE.THIS
Pubkey: http://pgp.mit.edu/pks/lookup?op=get&search=0xB5E3846CD40F08E3
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJW7warAAoJELXjhGzUDwjjI6wIAIIDcJ1OeODexXJGMQmF+/pb
MJv1tqccLtQ7MKbV/SsrT4C7ULiKVxu9v/5+Zin3oCqSHQH2ChUIjJ+a2rWc0G+y
a4+y1XRFGT9xUIGABwsj6pLP6uc1BXEfs06SMEn0ScbzZ8W8H+E2Oz34l9baC+k1
nhx7Ds6w24AyCxQtcPCsJjlas+E9YO4/xufDs6Ba91pjLeRmHfr/8gviTkzX5BQw
jiOJQfhCM2ZjuWk5dtjXcay96bMiP86HRqd6aNcnYYvllkAxP1nxA9+jtK2Bx/Lk
7gbF3rVHm3de5bKUpwGI5GDzmqBso75faTKtpD7XtDplJ3B12VlaHLuGoTb9u+c=
=gLWs
-----END PGP SIGNATURE-----

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

