Hacker News Reader

Comment by sp332 | Hacker News Reader

From an email further down in the thread https://lists.torproject.org/pipermail/tor-talk/2015-April/0...

While these relays account for 6% of the total number of exit relays, they only sum up to 2.7% of exit probability, which is what really matters.

Almost all of them were younger than one month and they seem to have joined the network in small batches.

https://lists.torproject.org/pipermail/tor-talk/2015-April/0...

the diversity here is interesting. My hunch is that we are looking at 38 popped boxes.... The question to me is: Do they all have something in common? What was the vector of compromise?

Curiously enough, they all run Debian stable (according to the SSH version string "SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2” ALL of them spit out on port 22 — no exception!).

View on HN

70 exit nodes less than a month old all running the exact same config doesn't seem like a state actor to me.

Lizardsquad had thousands of exit nodes spun up all running the exact same config. It doesn't take state actor effort to do this.

Attacks like that are easy to spot and easy to shut down. New exit nodes gain trust over time, so having a bunch of brand-new nodes is not as useful as having a few dozen old, trusted nodes. This looks like an experiment, not an attempt to take over the network.

> While these relays account for 6% of the total number of exit relays, they only sum up to 2.7% of exit probability, which is what really matters.

If that probability is on a per-tor-session basis, that is actually not very in favor of the user. My combinatorics are a bit rusty, but wouldn't your odds of being in the 2.7% increase significantly each time you use the tor network?

Your Tor session should change exit nodes at least once every 10 minutes.[1] Ignoring everything else (e.g. pressing the new session button on TBB, restarting the browser, failed connections etc.), this gives us

  p(using a bad node)=1-(.973)^(t/10)

where t is how many minutes you've been using Tor. So if you've actively used Tor for more than 4 1/2 hours over the past month, it's more likely than not that you've used one of these nodes.

[1] https://www.torproject.org/docs/faq.html.en#ChangePaths

Tor uses entry guards [0] to mitigate this kind of an attack.

[0]: https://www.torproject.org/docs/faq.html.en#EntryGuards

Entry guards do nothing for bad exits... sticking to particular exits across sessions would significantly harm your privacy in a way that entry guards do not.

After 25 times, you'd have a 50/50 chance of having gone through those nodes at least once.

I don't think so because the chance of using a node is an independent event. So you will most likely have the same chance every time.

Right! I mean cumulatively, after connecting 25 times, you have a 50/50 chance that at least one of those connections went through one of these nodes. (1 - 0.027) ^ 25 ~= 0.5

Nit: I think that should be 1-(1-.0.27)^25 ~= 0.5. Obviously it ends up being about 1/2 either way, but you're measuring the chance that you used one of the nodes, not that you avoided all of them.

Interesting analysis. And that's absolutely correct, the exit probability is what makes the difference.

It could be that they were all popped boxes running the same config, or it could be basic devops making sure all boxes setup have the same config. Both seem equally plausible, IMO.

I'd guess all of them are VPS instances. When you order a VPS, most hosts will run a full OS update before delivering it to you. (this is a feature of cloud-init, which is fairly standard) So, if you ordered all Debian instances at the same time, they'd all have the same SSH version string even if you didn't do anything special.

Reply on news.ycombinator.com