[tor-talk] Traffic shaping attack

[Mike Perry]

Oskar Wendel:
> Mike Perry <mikeperry at torproject.org>:
> 
> > 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.
> 
> 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?
> 
> 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-discovery.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?
> 
> Unfortunately, only the site admin could confirm, but I don't see him 
> here (he has been notified of this thread).
> 
> Actually, as I don't know the site admin in person, it would be possible 
> that the site admin is already in jail and the site is being run by LEA, 
> inserting these interruptions deliberately. But for now let's assume it's 
> 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.
> 
> Yes, definitely.
> 
> > 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.
> 
> It would have to run within a realtime scheduler to completely block Tor 
> for several seconds... very few applications use this scheduler, at least 
> 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.
 

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20160420/d5a8f203/attachment.sig>