Slashdot Mirror
Black Hat Researchers Actively Trying To Deanonymize Tor Users
An anonymous reader writes: Last week, we discussed news that a presentation had been canceled for the upcoming Black Hat security conference that involved the Tor Project. The researchers involved hadn't made much of an effort to disclose the vulnerability, and the Tor Project was scrambling to implement a fix. Now, the project says it's likely these researchers were actively attacking Tor users and trying to deanonymize them. "On July 4 2014 we found a group of relays that we assume were trying to deanonymize users. They appear to have been targeting people who operate or access Tor hidden services. The attack involved modifying Tor protocol headers to do traffic confirmation attacks. ...We know the attack looked for users who fetched hidden service descriptors, but the attackers likely were not able to see any application-level traffic (e.g. what pages were loaded or even whether users visited the hidden service they looked up). The attack probably also tried to learn who published hidden service descriptors, which would allow the attackers to learn the location of that hidden service." They also provide a technical description of the attack, and the steps they're taking to block such attacks in the future.
But I have my doubts about about technological fixes to the jackboot/battering-ram/nightstick vulnerability.
I find it kinda funny that TOR is used by many Black Hats is being hacked by Them. TO expose who they are...
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I wonder how feasible it would be to modify tor, or maybe make a tor version 2 protocol so that the onion layers are determined packet by packet, instead of by the stream.
I'm not all that knowledgeable when it comes to the tor protocol, but it sounds like each stream is bounced off a series of relays.. If you could change that to each packet, or split the stream into a few other streams that took different routes (and let the stream get reassembled from packets from multiple streams at the destination), then it seems like you could make this sort of attack a lot harder..
I'm not sure about people trying to discover the location of the tor hidden service, but it seems like it would help protect the client -> server integrity quite a bit..
Fascinating. If they can detect suspicious fraud nodes, TOR could build into their project a blacklist support that they publish and honor in their code. Then it becomes a whack-a-mole issue, which is better han the current situation.
Ummm...what with Russia trying to de-anonymize TOR and all. Bad Rooskies.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Black Hat Researchers Actively Trying to Demonize Tor Users
Then I thought it was perhaps
Black Hat Researchers Actively Trying to Deamonize Tor Users
Before I figured out they meant
De-anonymize
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
apparently 3 proxies aren't enough, should rather be 7 :-)
And sure as hell it is impossible to develop a mixnet that will generate Camouflage traffic
It would have to generate traffic in equal amounts for every flow, which would halve network speed to give an attacker a 50/50 chance of guessing the correct flow. Those fake flows would also have to be carried to something that looks like a reasonable endpoint as well.
PRISM-level metadata collection makes it trivial to see which computer sent the original 682-byte request (recurse as necessary until the 800 byte request starts at the "sender") as well as which computer the multi-megabyte response was sent to (recurse as necessary until the multi megabyte response returns to the requesting computer). Camouflage traffic can't fix this on its own, it's easy to exclude the data that wasn't requested from the analysis.
I think that Tor's best bet while maintaining performance at this point would be to round all packets up to the nearest MTU (lets say 1400 to account for PPPoE, VPNs, and other layers on ethernet), so every request and response becomes a multiple of 1400 bytes, would make most tracking rely on packet timing. The next step would be to introduce packet delays at each hop, but that will slow the already slow network down.
If I have been able to see further than others, it is because I bought a pair of binoculars.
It's because Russia's offering $$$ for a TOR hack...
http://www.themoscowtimes.com/...
on the bright side, TOR will be better in the end because of it.
I see many naysayers & detractors here querying why black-hats would want to break the very services they rely on, but surely that's exactly what they should be doing?
If you want to rely on a service for your own security, it's in your best interests to find all the weaknesses - especially with open source projects, which rely on the community to find & fix faults.
I don't think you can imagine a proper Camouflage scheme at this point. I do think I can. And yes, it would thwart correlation attacks. It might induce some delays for (say) ssh-over-TOR sessions which transmit very small packages. Camouflage would of course mandate a single package size histogram over a certain time frame. Many small payload packages would be stuffed in a single transport package, which means delay. Lots of dummy octets would be transmitted in the course of a browsing session. Bandwidth would be wasted. So what ? Save the bw for kitten videos ?
You are focusing on packet length patterns, which is only part of the whole story. The TLAs also have the ability to impress transmission-rate patterns onto TOR traffic. There are some papers out there which demonstrated good results (from the TLA perspective) from that.
So next-gen TOR needs to handle both the packet length problem and the transmission rate shaping problem.
Finally, where did you get 3 modpoints from ?
Since you're not sharing, I'm guessing you're imagining some sort of multiplexing scheme where the node would take say 100 bytes from 14 different sources and combine them into one packet and send that. It's an intriguing idea that would slow down metadata analysis but it would have a lot of overhead to keep track of, but that "keeping track of" becomes an attack vector again especially with subverted nodes, since node B will need to know that the next 8 packets from node A will have 100 bytes of data that need to be kept together and sent on to node C.
If the network is busy it should actually not be bad for interactive small-packet connections. If the network is idle there could be a timer before the node fills unfilled slots with random data and sends it.
If I have been able to see further than others, it is because I bought a pair of binoculars.
"We spent several months trying to extract information from the researchers who were going to give the Black Hat talk, and eventually we did get some hints from them about how "relay early" cells could be used for traffic confirmation attacks, which is how we started looking for the attacks in the wild. They haven't answered our emails lately, so we don't know for sure, but it seems likely that the answer to Q1 is "yes"."
Fucking slashdot, can't even be bothered to RTFA to check the headline. It's only suspected, not proven, that black hat researchers did this.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
I think the answer lies in figuring out how to increase throughput on bitmessage networks.
RIP TRICERATOPS, YOU NEVER EXISTED