Tor security advisory: “relay early” traffic confirmation attack | Hacker News Reader

Tor security advisory: “relay early” traffic confirmation attack

blog.torproject.org

197 pointsohmygodel45 comments

First rule of security: There is no perfect security. You need a multilayered strategy. Tor is a start. Anonymized OSs like Tails are another aspect. Not releasing personal info on the web -- to the extent you can do that -- is another.

Ironically only one of my friends has gone that far on the last count. He is an attorney and very persistent, and many of these companies do claim to clean up all his data when he writes letters with the proper legal wording to signal they need to take it seriously. It is time consuming, but these letters paid off. Only one of the scummy German screenscraper sights did not comply, and ignored him. I cannot find him anywhere if not for the email address he sent me years later, and no other mention of life exists.

> I cannot find him anywhere if not for the email address he sent me years later, and no other mention of life exists.

I guess his job does not involve participating in projects that have git repositories or public mailing lists.

That is just not true. The email address in git does not need to exist. It just has to look like one, you can use for example `anon@example.com`.

Moreover, I know more important and intelligent people than I are interested in such things, but if you want a C++ SCM system that has strong signing and allows for pseudo-anonymous development, check out Monotone. I had trouble using it and building it with Lua 5.2 after core Lua API changes. Nonetheless, it is what the I2P project uses, and i assume they take such things seriously for a reason.

"but these letters paid off"

What was the benefit to having no electronic record? Was he a lawyer for the mob?

He just wanted his privacy. On HN, I am kind of surprised that had to be explained. Is that not the norm we are fighting for when discussing such things?

There is an anti-privacy demographic on HN, ex - https://news.ycombinator.com/item?id=8111288

It makes sense though, so many people run companies that sell, exploit, mismanage, abuse user data, or outright ignore privacy issues that it's bound to leak into HN as well. It's unfortunate.

Would your friend be kind enough as to open source his letter wording so others may benefit from this approach as well?

I am curious if I ask I can publish a howto following his steps.

I will ask.

Is this problem even solvable on a fundamental level?

Of course, they can work on preventing nodes forwarding hidden header information, but an entity with global network insight will always be able to correlate users by the timing of their transmissions alone.

The introduction of malicious nodes is a workable option for lesser players. But hidden in the realtime nature of the Tor network is always the possibility of deanonymizing users if you're a powerful agency that can afford to inspect a sufficiently large part of all network traffic - they don't even have to run any nodes themselves.

> but an entity with global network insight will always be able to correlate users by the timing of their transmissions alone.

For what it's worth, this type of adversary is explicitly excluded in Tor's threat model[0].

[0] https://svn.torproject.org/svn/projects/design-paper/tor-des...

Sure it is; it's just impractical. If you force the entire network to play by certain timing rules and mangle the traffic in a uniform way it'd be very difficult to analyze the network to discover unique patterns. But this might also make the network impractical to use for anything but Twitter and e-mail.

Which was my point when I referred to the realtime constraint...

Yes, you just have to think about networking a little differently. The problem is that we share documents over connections. Immutable documents don't really need to get to you immediately, especially now that we have webapps with UIs which update instantly and which can perform non-trivial computation.

Onion routing with something like Mixminion[1] works much like Tor, but instead of establishing connections it passes messages between routers. Messages are arbitrarily delayed, preventing even traffic analysis from finding you.

However, using an anonymous remailer like Mixminion would require completely rethinking browsers and our protocols for web browsing. They simply aren't designed for a world where packets might take minutes to get to you.

[1] http://en.wikipedia.org/wiki/Mixminion

You're the second commenter to say that the answer to me having doubts if we can even in principle have an anonymous instant-tranfer network is: "yes, you just have to drop the instant part" ;)

>Is this problem even solvable on a fundamental level?

I think it is, though it may never be practical. In theory, you could have every node everywhere constantly streaming encrypted noise to every other node, and when you actually want to communicate something, you just switch out the noise for something you actually care about. You'd never know who is actually talking and who is just sending noise.

As you can imagine, that would take a lot of bandwidth and probably a lot of computing power, but it would have very high latency.

EDIT: To clarify, I mean nodes on the network, not relay nodes. Potentially you could use a relay system, but that wouldn't be necessary if everything on the network was constantly in connection with everything else on the network.

Maybe something based on the Dining Cryptographers? https://en.wikipedia.org/wiki/Dining_cryptographers_problem Someone actually implemented it, but it didn't seem very practical. https://www.youtube.com/watch?v=4BQQcoROQoI

"So if the attack was a research project (i.e. not intentionally malicious), it was deployed in an irresponsible way because it puts users at risk indefinitely into the future."

I'm disappointed nobody has "leaked" the research so far. If they cared enough to research it in academia, surely they know it's important enough for Tor developers to know about the type of attacks they were performing, despite what any government officials might say? At least some hints should be leaked, if not the whole research.

That wouldn't really be ethical would it? It would do more harm than good, such as get a lot of people arrested, tortured, killed, and discovered as spies.

Responsible disclosure is best, get it patched then release the details of the vulnerability.

There is a limit. You're also keeping information from the victims who can't protect themselves without your information.

You do realize that "leaked" information on the TOR network could cost an activist their life?

Leaking hints is the dumbest conceivable way to handle disclosure. It taunts the community and sets up a race to independently find the flaw. The race happens much more openly than the original research, meaning that flaws are incrementally disclosed, ensuring that bad actors of every skill level will get a crack at the attack before it's fully fixed.

Don't ever do this, at least not for a bug that matters. It would be better not to disclose at all than to do this.

It sounds like to be truly safe you need to know safe entry guard node(s) and/or operate your own group of entry relays. Otherwise, you risk X% of your traffic potentially being deanonymized by someone controlling both ends.

Of course, if you do that, you probably need to remain constantly connected and moving data through Tor 24/7 to prevent any kind of analysis since you can't hide the fact you:

A) Control the relay you connect to.

B) Are connected to Tor.

> you probably need to remain constantly connected and moving data through Tor 24/7

You almost have it. The problem is that just moving data through isn't enough. Given enough sample data, you can eventually figure out enough information about the traffic to correlate with another host moving the same traffic.

The most effective way to mask the effects of passive statistical analysis is to employ either a masking effect or a countermeasure. Either make all the traffic look identical (and have its rate be identical and constant), or make all the traffic look random, insofar as garbage is injected or frames are truncated at every hop.

Also, you don't have to control both ends. You just have to observe a given percentage of the traffic along its path(s), and you can determine a probability of which hosts lead to/from what traffic. If you're just trying to trace an unknown adversary, it may be able to [at the very least] identify the network they're on.

> Also, you don't have to control both ends. You just have to observe a given percentage of the traffic along its path(s), and you can determine a probability of which hosts lead to/from what traffic. If you're just trying to trace an unknown adversary, it may be able to [at the very least] identify the network they're on.

Really? I figured the number of hops involved meant as long as they couldn't control both Entry Guard & Exit Node you were relatively safe.

> The most effective way to mask the effects of passive statistical analysis is to employ either a masking effect or a countermeasure. Either make all the traffic look identical (and have its rate be identical and constant), or make all the traffic look random, insofar as garbage is injected or frames are truncated at every hop.

So, setup a webcrawler whenever you aren't using it that randomly crawls pages I suppose. Random garbage would make you easier to find, I suspect, since it doesn't fit with a "normal" pattern of any kind.

I mostly look at Tor out of curiosity. :)

I don't like the idea of 'relative' safety. I trust tor about as much as the extradition treaty of the country i'm using it from. And no, there's been many attacks on the tor network that have been successful without controlling the ingress & egress nodes.

Webcrawlers have a pattern too. The point is to generate garbage in such a way as to make the traffic indistinguishable and as random as possible, while still embedding a real payload. It would not be easy. The timing is often more telling than the data, though.

Fair enough. :)

> Webcrawlers have a pattern too.

Nope. The ones that have a pattern are the ones that play by the rules. It's extremely easy to write a web-crawler that performs random actions (download torrents, seed data, make bing/yahoo/google/duckduckgo random searches and click on 25 random indexed results, etc.).

In order for a sniffing party to understand what it's going on, it will (probably) take a Bayesian approach which will require more data than one can generate in 100 years.

Writing such a crawler for an experienced developer is extremely trivial (e.g. ruby + mechanize + nokogiri).

https://blog.torproject.org/blog/bittorrent-over-tor-isnt-go...

> download torrents, seed data,

I'm not sure that part of your idea is good.

The random crawler is what I had in mind but I doubt I'd implement it simply because I don't have a need to use Tor beyond curiosity.

Yeah okay, torrents aside, the idea is to generate random bursts of data transmission and you can do that easily.

What is that even supposed to solve? You're just making random network connections... it really does nothing to obscure origin or destination. It's not the target traffic so it'll get filtered out, and timing attacks still work on the target data.

> you probably need to remain constantly connected and moving data through Tor 24/7

I guess this is why they recommend running a (non-exit) relay – at the very least it increases the cost of figuring out when you're using Tor yourself.

It's still vulnerable to passive analysis as the other guy noted since if you control the ISP for the end-user you have some idea how much data is being pumped through an encrypted connection. [e.g. Is it just staying alive or pulling 50mb/s?]

Please will a mod rename the title? The blog post explicitly says (at the bottom) that we don't know if this is the Black Hat talk that got cancelled early.

Whilst they do say that they don't know, they do also say that it "seems likely", and provide some fairly convincing evidence for that reasoning.

But yes, the title doesn't quite reflect that.

This title made me think, "wow, the Tor team is usually pretty on-the-ball, did they really write a sentence that started with 'Black Hat researchers', as if that was a thing?"

It's a truly bad title; it editorializes, it's contradicted by the article ("maybe" is not "affirmatively"), and it confuses its subjects with the venue they happen to present at (think about how nonsensical "ACM researchers do X" or "USENIX researchers do Y" sounds).

Someone posted the same article with the original title on HN earlier and it sank without a trace, whereas this one seems to have stuck. Apparently it's a pretty good title from that perspective.

Yeah. Stupid honesty. Who needs it?

You could use some yourself. And maybe some altruism to go with it...

https://news.ycombinator.com/item?id=8107273 which goes to https://lists.torproject.org/pipermail/tor-announce/2014-Jul...

> Apparently it's a pretty good title from that perspective.

There's a lot of randomness in which stories get uptake and when.

We need to put that on a tshirt.

Yes. The submitted title ("Black Hat researchers actively attack Tor users") violated the HN guidelines.

Reply on news.ycombinator.com