[tor-talk] Traffic shaping attack

notwith at sigaint.org notwith at sigaint.org
Fri Mar 25 15:44:39 UTC 2016


I've just subscribed to the list, sorry for late replies.
I'll add few details to this discussion.

krishna e bera:
> What evidence have you seen?

Roger Dingledine:
> This assumed scenario seems extremely unlikely to be happening in
> practice.
> 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.

I don't know how it is done. One time admin mentioned onionbalance, so he
knows
about it. He didn't tell explicitly he uses it, but I suspect he does.

Admin's words "well over 6 TB of traffic per day" roughly means 80
MBytes/sec is
an average speed. Well, it is less than 1gbit/s (128 MBytes/sec), but it is
still high for the average connection speed.

This onion site has more than 200.000 registered accounts, but it doesn't
tell
how many of them are online at the same time. In fact, the site is popular.
Registration on the site is often disabled. If it is not disabled it requires
invitation code which is not secret but for many users is a problem to find.

Download speed for single file varies from about 100 KBytes/sec to 1
MByte/sec.
The site supports 6 simultaneous downloads. Total speed of all simultaneous
downloads is about 1 MByte/sec. If 80 MBytes/sec is average speed, about 80
users use it in each time moment.

If "new identity" is used for the site while it is already downloading 6
files,
extra 6 downloads can be launched at the same time. So, 12 will be in total.

When many downloads are active at the same time if one of them stops, most of
others don't. Downloads which are started after "new identity" action are not
"interrupts-correlated" to downloads started before "new identity" action.
Downloads started before "new identity" may be correlated each with other (if
one stops, other stop too), may be not. Correlation of interrupts between
them
is observed, but it is not so strong to tell about reliably.

This is what HS admin wrote about it:

"I see the same thing, it's mostly to do with server and tor relay load. I
doubt
it be better for creating a unique signature than simply looking at the
download
speed itself."

It is not clear what he means. Is it HS server side or HS client side?

There are two other onion sites which could have high traffic speeds:
http://obscuredtzevzthp.onion
http://nk3k2rsitogzvk2a.onion/index.html
I've never seen any regular interrupts with them.

The interrupts for _that_ site we discuss don't happen always, but very
often.
It may be so that if proper circuit is chosen, interrupts are not observed.
I don't have reliable stat to confirm or deny it.

It may be not an attack, but some misconfiguration on server side. HS
admin is
notified about this tor-talk discussion. He could explain better what is
going
on.

I checked metrics for a long period of time:
https://metrics.torproject.org/hidserv-rend-relayed-cells.html?start=2013-12-26&end=2016-03-25
Note 5 short downfalls from September of 2015. All of them are decreasing
of the
total speed to 600 Mbits/sec. Are these downtimes of _that_ HS we speak
about? I
don't know. It looks as artificial as "we have only a single Tor HS with the
speed linerly growing with time, while total speed of other HS sites
(about 600
MBits/sec) is almost not changing."

> More details please? This is not a crazy possibility, but it would be good
> to know exactly what evidence we have for its being true. 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.

Mike Perry | 20 Mar 23:14 2016:
> 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.

I don't think we can do much if HS admin doesn't cooperate. Is there some
soft
which can record how speed is varied in Tor circuits?

grarpamp | 20 Mar 23:49 2016:
> ... the OP appears to know the onion url and refers to fora
> discussion the situation. So OP should post those links for
> others to review analyse formulate hypothesis etc. Not as if OP
> and all have not already been shaped / confirmed themselves or
> that links [to links] mean anything.
>
> Oh noes, thousands links in your mbox...

Yes, link is known. This HS is in your HS list but it is unnamed there.
The HS
requires registration to download, and registration is now closed. So, the
link
without valid username and password is useless. I could post everything I
read
from other users, but I doubt it is allowed in tor-talk to mention links to
illegal sites.

coderman | 21 Mar 07:27 2016:
> attacks attempting to confirm a solitary client connecting to a peer
> (e.g. very low degree node) are at different risk than those highly
> centralized, very active services experience.

I think HS admin understands it well. This type of sites never lives long.
One
year is already a very long lifetime.

In this discussion I've read many words about guards. They may be not so
important for this attack as guard mixes traffic of many suspected users.
What
is important is ISP. If HS is under this modulation attack, any ISP in the
world
can easily compare statistics of all his Tor users to statistics of HS
interrupts. The more interrupts happen, the more reliable the detection is.

I want be completely wrong in my guess. If I am not wrong, the number of
deanonymized users can be as large as the number of victims of CMU attack.
As it is not the attack on Tor browser, nothing will help.



More information about the tor-talk mailing list