Oskar Wendel: > Roger Dingledine <arma@xxxxxxx>: > > >> 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." 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. > > 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? 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 :/. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
-- tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk