Delivery-Date: Wed, 20 Apr 2016 17:46:56 -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 AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id DF6C01E0B0D;
	Wed, 20 Apr 2016 17:46:53 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id E45EA3B307;
	Wed, 20 Apr 2016 21:46:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 487553B2F8
 for <tor-talk@lists.torproject.org>; Wed, 20 Apr 2016 21:46: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 jYdOmCj4_1Aj for <tor-talk@lists.torproject.org>;
 Wed, 20 Apr 2016 21:46:46 +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 1CE823B082
 for <tor-talk@lists.torproject.org>; Wed, 20 Apr 2016 21:46:46 +0000 (UTC)
Date: Wed, 20 Apr 2016 14:47:37 -0700
From: Mike Perry <mikeperry@torproject.org>
To: tor-talk@lists.torproject.org
Message-ID: <20160420214737.GC18864@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>
 <20160320221427.GE15350@torproject.org>
 <nd69v5$qjt$1@ger.gmane.org>
MIME-Version: 1.0
In-Reply-To: <nd69v5$qjt$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="===============4733592235592272042=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


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


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

Oskar Wendel:
> Mike Perry <mikeperry@torproject.org>:
>=20
> > 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.
>=20
> Yes, I agree. But the attack is very probable here.

I think you may be right, or at least prudent. Perhaps for the purposes
of motivating us towards rigorous analysis, let's assume the worst case
here, and see what more we can uncover.

> > 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?
>=20
> Only with hidden service traffic from this specific service.

Ok. So then if this was an attack, then we are actually looking at a
combination of multiple attacks. First, since this attack was highly
targeted, this means that before the traffic shaping happened, some
other attack allowed the general location of the hidden service or its
Guard node to be discovered, and then that uplink was targeted for
traffic shaping.

If the traffic volume estimates are correct, this first attack could
have been the enormous traffic volume that an intelligence agency
observed and illegally reported for purposes of parallel construction
(aka: lying to courts, juries, judges, and the public). However, it
could also have been Guard discovery (See
https://gitweb.torproject.org/torspec.git/plain/proposals/247-hs-guard-disc=
overy.txt).

Things like OnionBalance (https://github.com/DonnchaC/onionbalance),
custom padding hacks, and custom Tor path selection implementations
*may* mitigate *some* forms of this first stage, while we work towards
general solutions like Proposals 247 and 254. Sloppy deployment of these
things could also just make sites more vulnerable, however.


Based on what you have reported, the second stage traffic shaping could
be due to some kind of in-line traffic shaping device, though it could
also still be due to targeted denial of service attacks against specific
nodes in the network.

Remaining open questions for the secondary traffic shaping attack
include:

1. Did the operator try running test hidden services or test torified
downloads from the same locations using the same Guard nodes, but
different Tor clients/machines?

2. How about from the same exact Tor client, but for non-HS activity
(to make use of the same TLS connections to Guards, and test if the
Guard itself is using extra information to do fine-grained targeting)?

3. How about the same Guard nodes from different locations? OnionBalance?

4. Was the hidden service itself subject to heavy internal (ie CPU) or
external network load at the time of shaping events?

> > I am wondering the same thing about the hidden service side. Is it
> > seeing interrupts of all traffic, or just some?
>=20
> Unfortunately, only the site admin could confirm, but I don't see him=20
> here (he has been notified of this thread).
>=20
> Actually, as I don't know the site admin in person, it would be possible=
=20
> that the site admin is already in jail and the site is being run by LEA,=
=20
> inserting these interruptions deliberately. But for now let's assume it's=
=20
> not true.

Thank you for not disclosing the name of the hidden service, despite
requests otherwise (note: I have not viewed any of the links in this
thread).

It is always best practice to avoid disclosing specific identifying
information, jurisdiction, or activities about any site that is under
attack (or having issues in general). That information doesn't matter to
me, and knowing that information can create risk for the Tor Project
and/or other parties on this mailinglist, depending on the jurisdiction
involved.

I only care about the incident on a technical basis as a case study in
security/stability of the Tor network, and am willing to diagnose the
issue to that end, so long as the conversation remains useful and
productive.

> > 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
> Yes, definitely.
>=20
> > 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.
>=20
> It would have to run within a realtime scheduler to completely block Tor=
=20
> for several seconds... very few applications use this scheduler, at least=
=20
> in Linux.

Well, no. One could still shape traffic by DoSing the Guard nodes or ISP
uplinks in question in various ways (CPU or otherwise). Depending on the
severity and targeted nature of the DoS, its effect may still be
detectable at other observation points, regardless of the scheduler in
use on any of these systems.

However, like Roger said, these attacks will still have false positives,
and will need to be highly targeted with lots of extra information to
filter out exactly when/where to observe, and even then, likely run over
a long period of time.
=20

--=20
Mike Perry

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

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

iQIcBAEBCgAGBQJXF/j5AAoJEOI7sywPEpQCSsUQAL5pQORHpqoqRLXJUP0pR6z/
CY4Jx98npES25INWS2TyXi5mbuwbZ75gg3u5h3cMRplNgm0A0bQumuJluGZK8Nhv
SzHR8vkx/H77leT3DtJUpvT0U+as09XFhjT186f6VxU7W+j0qyYsOI88A4DeZyad
Cvsv24QFNrbPpmqoyznrkyypGunp68TJZjltI6BI/GyOU29OueDJONuorIySeMkd
zi5w8eKIiF5/AyiZduL2jxKvHI0QmmQZa8CTiW0+1pQekpQcTIVEmvFln/jfW1nZ
PspdxNaBByuBtjart+uoHzazi1Xp+kGGvp0+7ij0zZWixDzfOXGbiuRiMJAX2hO5
IJG/c9yfz99OUIJHTsDV9i/bcxVuSD5yJSWi34SUDgz1o1tFgPIupeIuBevhRpJI
0+FEToy67R3ig/3E1YSlt1H7CkAO7H/sP9tLpm1rPSL5dwE99PNKllt0dNMoYsxB
N92/SaX65lcDRxIvTz4kdoTVm5jQd9bmP1xocSToBSTsJdiQjZOqdanxK43twfrE
FLt3JHgY5Zow2pwvwdGt3WdjBP4LtApLlQCusYHHx1jQMmP8RPs7m8oUv9CyDahB
zPGsdXNCWwPRkT3GyewqVVVBsPJHE4lfApEkKXEumrEvkjAOc2p3axeXFiAn8P/X
o12U7QhNUVRehrpA0Oj7
=coni
-----END PGP SIGNATURE-----

--Yylu36WmvOXNoKYn--

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

--===============4733592235592272042==--

