Oskar Wendel: > Mike Perry <mikeperry@xxxxxxxxxxxxxx>: > > > 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
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