The way we generally explain it is that Tor tries to protect against traffic analysis, where an attacker tries to learn whom to investigate, but Tor can't protect against traffic confirmation (also known as end-to-end correlation), where an attacker tries to confirm a hypothesis by monitoring the right locations in the network and then doing the math.Īnd the math is really effective. That's why Tor's security is all about trying to decrease the chances that an adversary will end up in the right positions to see the traffic flows. That's because if you can see both flows, some simple statistics let you decide whether they match up.īecause we aim to let people browse the web, we can't afford the extra overhead and hours of additional delay that are used in high-latency mix networks like Mixmaster or Mixminion to slow this attack.
The Tor design doesn't try to protect against an attacker who can see or measure both traffic going into the Tor network and also traffic coming out of the Tor network. Tor clients route their traffic over several ( usually three) relays, with the goal that no single relay gets to learn both where the user is (call her Alice) and what site she's reaching (call it Bob). This blog post aims to give you some background to get you up to speed on the topic.įirst, you should read the first few paragraphs of the One cell is enough to break Tor's anonymity analysis:įirst, remember the basics of how Tor provides anonymity.
But it's also important to realize that traffic correlation attacks are not a new area. It's great to see more research on traffic correlation attacks, especially on attacks that don't need to see the whole flow on each side. People are starting to ask us about a recent tech report from Sambuddho's group about how an attacker with access to many routers around the Internet could gather the netflow logs from these routers and match up Tor flows.
0 kommentar(er)
