Delivery-Date: Sun, 20 Mar 2016 18:13:52 -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 5833B1E0AA9;
	Sun, 20 Mar 2016 18:13:50 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 122D531E42;
	Sun, 20 Mar 2016 22:13:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id AE54C220EB
 for <tor-talk@lists.torproject.org>; Sun, 20 Mar 2016 22:13:41 +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 SLkesESZtkBs for <tor-talk@lists.torproject.org>;
 Sun, 20 Mar 2016 22:13:41 +0000 (UTC)
Received: from turtles.fscked.org (turtles.fscked.org [76.73.17.194])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 858C521DCE
 for <tor-talk@lists.torproject.org>; Sun, 20 Mar 2016 22:13:41 +0000 (UTC)
Date: Sun, 20 Mar 2016 15:14:27 -0700
From: Mike Perry <mikeperry@torproject.org>
To: tor-talk@lists.torproject.org
Message-ID: <20160320221427.GE15350@torproject.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> <ncn0rr$1jm$1@ger.gmane.org>
MIME-Version: 1.0
In-Reply-To: <ncn0rr$1jm$1@ger.gmane.org>
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: multipart/mixed; boundary="===============1444793327182527908=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


--===============1444793327182527908==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="BQPnanjtCNWHyqYD"
Content-Disposition: inline


--BQPnanjtCNWHyqYD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Oskar Wendel:
> Roger Dingledine <arma@mit.edu>:
>=20
> >> Let's assume that the service is extremely popular, with over 6 teraby=
tes=20
> >> of traffic each day, and a gigabit port almost constantly saturated.
> >=20
> > 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 whi=
ch
> > 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.
>=20
> Actually, I blindly told what the site admin published:
>=20
> "I strongly suspect it's the highest traffic site ever to exist on Tor.=
=20
> That's why it's gotten so expensive to run, we use close to 100% of a=20
> gigabit internet port much of the time, pushing well over 6 TB of traffic=
=20
> per day."
>=20
> I'm not sure if it's true (and from what you say, it seems it's not), but=
=20
> the site is very active anyway.
>=20
> >> This is not a theoretic attack. This is something that has been notice=
d=20
> >> on one of illegal sites and I expect many busts around the globe in th=
e=20
> >> coming weeks.
> >=20
> > More details please?
>=20
> A couple of users recently noticed this repeatable pattern during=20
> downloads. From what they told, downloads from this site were always=20
> smooth and, although the speed have always been fluctuating, it rarely=20
> stopped completely, and even if it did, it was random. Now, when it=20
> occurs (because it doesn't occur every time), it occurs perfectly=20
> repeatedly.
>=20
> To quote one of the users: "Yes, speed can vary, it is normal and observe=
d=20
> everywhere in Tor, but it is NOT frequent INTERRUPTS. Normally speed=20
> changes monotonically, so if interrupt happens, it happens only after the=
=20
> speed decreased to just a few KB/s. If speed is perfect, very high, and=
=20
> then sudden interrupt happens, it is very warring sign. This may be new=
=20
> FBI technique."

I'm still with Roger on being careful about assuming its an attack (and
not a bug, or other emergent behavior) before conducting more tests. At
least, that is what proper engineering and science demands before we can
respond, anyway.

For example, I wonder if users see such interrupts on all of their Tor
traffic at that time, or just hidden service traffic? Or just hidden
service traffic to specific services?

I am wondering the same thing about the hidden service side. Is it
seeing interrupts of all traffic, or just some?

If this is an attack, this information could help inform us as to if
we're looking at an attack targeting all users, certain guard nodes, or
just specific hidden services. With this information, we will also be
able to better consider defenses, if it is an attack.

Even if it is not an attack, it would still be useful to know, because
we may be looking at some other kind of bug or bad emergent property in
Tor.
=20
> > This is not a crazy possibility, but it would be good to know exactly=
=20
> > what evidence we have for its being true.
>=20
> The only evidence I have is how the site started to behave, and what=20
> the users noticed.
>=20
> > For example, if somebody noticed "I get a burst of cells from this onio=
n=20
> > service, then a few seconds of silence, then I get another burst of=20
> > cells", that's actually a property of our current load balancing=20
> > algorithm, and not necessarily evidence of an intentional signal being=
=20
> > injected into the circuit.
>=20
> When this load balancing algorithm starts to work? When it is used (to=20
> balance load between what and what?), and what can be the reason it=20
> started to behave that way only recently?

I think Roger is talking about our windowing mechanism (Sections 7.3 and
7.4 of tor-spec.txt:
https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt#n1542). He
could also be talking about interactions with TCP and the multiplexing
of many users' traffic over a single connection, as grarpamp alluded to.

It could also be due to the fact that Tor is effectively
single-threaded. If something on the user's guard node, intermediate
node, or hidden service is taking large amounts of CPU time, this will
prevent traffic from flowing while that operation is happening. See:
https://trac.torproject.org/projects/tor/ticket/16585 (though that
ticket could use some help with clarity).

That single-threaded issue may be exploited by an attack, or it could
just be happening naturally. Again, more analysis needed :/.

--=20
Mike Perry

--BQPnanjtCNWHyqYD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJW7yDDAAoJEOI7sywPEpQCn7IP/ijlZLkQnBzqvR+8tPHwVWim
KhyKCbcWOJScl00pEbUFGCneBIDBYvSGZrZGIepbKCx0Y2AjbFQrwN+7xVbghLpS
xKYMR8cJW2zRNw5EOTYRZyyOtvc+PPS3nOW+JfJtO/MSgBt+2E22HLpUlgk+Cei0
juxgCzty5FUVayKwR8RUwEx8SaHWtVHOmf/7Apu3vpYU2hegwUHEWH/FPljR7h9/
25EaAiq5gS1wz/sUUIf3nt8ivp/t5IY72PRQAiXoZB1aX7v+PRyiIQYGP2G+Dgbj
eEuVBKDCt0I92QimM9VkkATGVNr5s0v4sEAUabthjzcr8+xp0cczViq1RAeizqYg
D4H4i2fjs20KqcyVQUJ1TefCp7POMMjSCEfRgIi1ZDXtvz0NQmOUfgp5HVFzL+Po
tsnV25cA5jGiz8u+jLsZi/yHQ6KgxvLoZ3ejsqFun2C6pj1NpkDOvDf7O917p5OM
JfpLynhST1o8EOOD1j0UgzI+sA3wcQ1myJ1u/D5SYQAeg7aZhpknhZFwAwK/9mei
CXZWauZ657ESLXsVYTDw8tVR7BIWtgVQD3NB7xryU1lAwiYMNz1bfHnkjhyuvtKl
P1SOvCiR+UsKgDVNKQUGugFcHzRfAZ0O6OSPYDHTkmXjaIalBwJLo3jnN5z/9eyJ
jhUBf7xaMPaU+R8UhoFB
=JXCp
-----END PGP SIGNATURE-----

--BQPnanjtCNWHyqYD--

--===============1444793327182527908==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1444793327182527908==--

