Tor Project – Metrics | Hacker News Reader

Tor Project – Metrics

metrics.torproject.org

62 pointsTrouble_00724 comments

https://www.encryptionin.space/tracking-hsdirs-and-the-versi... tracks the fraction of HSDirs that are v2 vs v3 and the likelyhood of any random attempt to resolve a tor v2 address failing. Right now it's about 30%. So the old tor v2 still sort of exists and if it continues like this it will exist until brute forcing prefix collisions becomes feasible for trivial amounts of money. Right now it still takes quite a bit. Or, maybe the Tor project sees tor v2 still has users that don't want to stop, they will release a version with a consensus flag to block old versions that support v2 from the tor project controlled section of the tor network.

The tor project metrics used to have tor v2 and v3 overlayed on the same plots but now they're separate and the default date values are for v3 plotting, https://metrics.torproject.org/hidserv-rend-relayed-cells.ht...

Found a neat thing: Nearly 50% of Tor's Bridge users are from Russia[1]

[1] https://metrics.torproject.org/userstats-bridge-table.html

Its interesting that after the Ukraine invasion started, Tor bridges and relays haven't increased.

Anyone able to explain how Tor nodes (entry, relay, exit, bridges, onion/hidden service, etc) keep from getting hacked?

There are scripts that run constantly to detect any malicious relays or exits (if they are MITMing or http downgrading attacks) and if detected they are quickly removed from the network.

There are also dozens of volunteers who are monitoring for this activity as well and will report it.

You could in theory hack an exit relay and do some dirty work from it and blame it on being a "Tor exit" without much consequences.

I ran a Tor exit for 5 years before shutting it down over legal complaints.

If you spun up an exit and let it run for a month or two and then did illegal stuff from it could be easy to hide and blame it on Tor.

Mainly talking about keeping the machines from being hacked, not the Tor traffic; as this would be the first step any 3rd-party attacker would take; commonly hear about attackers spinning up servers to run attacks, never heard of servers being attacked, which to me seems like an obvious thing to happen.

___

That said, since you mentioned it, if the counter-measure you’re describing are similar to the ones described here:

https://security.stackexchange.com/questions/215155/how-does...

What’s to stop an attacker from just swapping back to the approved key if a “Tor auditor” connects to the machine — or — routing only a know targets traffic to an mitm key?

I replied to your other comment, but I see what you mean now in this context. Why is hacking individual Tor nodes with a common exploit not a more common method of exploitation compared to Sybil attack?

It’s a good question. Keep in mind that, while exit node IP addresses are public, it’s generally difficult (and sometimes impossible dependent on NAT) to enumerate all the IP addresses of non-exit nodes. You would need to operate a malicious directory server (probably not that hard) and/or crawl the DHT (new in v3, I’m not yet familiar with it).

I believe Tor also has explicit mitigations against this sort of enumeration, by eg directory server hashing the first bits of the client IP with a nonce for the current time period. But I don’t know the details and it’s been a long time.

It’s also worth noting that Zerodium has quite a large bounty for targeted deanonymization of Tor users.

You should assume every Tor instance is hacked. You should be concerned if a bridge is malicious and slightly concerned if an exit node is malicious. You can protect yourself by using application layer encryption like TLS which you can enforce with HTTPS Everywhere (an extension now included by default in the Tor Browser Bundle, anyway).

Frankly you should assume that all your traffic over Tor to clearnet is deanonymizable and you should act accordingly. For browsing Onion sites, you can be more confident in the integrity of your traffic, but keep in mind you also need to trust the operator of that Onion site not to get hacked or otherwise surrender whatever data you provide to them.

Possible missing something, but most of your response is what a user should do, not how nodes themselves secure themselves. Personally, I neither use Tor, nor would suggest anyone use it; that’s not really topic of this thread though.

Well, I certainly do have a propensity for replying to HN comments with tangentially related rants. Is there any other way to use HN? :)

In this case though, I guess I was challenging the idea that many Tor instances are _not_ hacked. And more-so, I wanted to clarify that the risk of using Tor is decoupled from whether any individual Tor nodes have been hacked. If a malicious actor can figure out how to slowly and quietly deploy a sufficiently high number of their own malicious nodes to the network, then they can compromise the anonymity guarantees of the network even while maintaining a fleet of perfectly secure machines.

Common knowledge that it’s vulnerability, and hacking is not required to gain significant control over network:

https://s3.documentcloud.org/documents/2719591/Farrell-Weds....

Again, topic is if what if anything Tor does to secure the nodes themselves.

By “Tor” do you mean the developers of the official and most popular Tor client, daemon and browser bundle?

I assume they fix bugs. I’m sure there are plenty of vulnerabilities left to find in the netcode of that software. And in fact, if I understand correctly, they’re in the middle of a huge rewrite to Rust, so there will soon be a bunch of _new_ vulnerabilities to find too (but yay for memory safety).

And thanks for the link btw. Pretty sure we agree with each other here. IMO the fact that Tor is able to somewhat peacefully exist without constant government harassment tells you all you need to know. It’s an extremely powerful tool - for surveillance.

#In Submissions : ( https://news.ycombinator.com/newsguidelines.html )

>If you submit a video or pdf, please warn us by appending [video] or [pdf] to the title.

Given the vulnerabilities in pdf files,

I think it would be prudent to applying a warning to the link, as HN truncates the displayed url

i.e.>Common knowledge that it’s vulnerability, and hacking is not required to gain significant control over network,

[pdf]: https://s3.documentcloud.org/documents/2719591/Farrell-Weds....

Thanks, though those guidelines are for submissions, not comment links.

>guidelines are for submissions, not comment links.

  As I Stated, in my humble opinion;

>I think it would be prudent to applying a warning to the link, as HN truncates the displayed URL

Safety First.

Please stop. No one is responsible for your safety but yourself. Also, you clearly linked and cited unrelated guidelines.

>Please stop. No one is responsible for your safety but yourself. Also, you clearly linked and cited unrelated guidelines.

Why are you requesting for me to stop posting? You came to to this thread from an article, which I posted, with security questions.

Yes, We all are responsible for our own security and safety, but do we not also have a moral duty,

and in some countries a legal responsibility to protect others? (i.e. hacking laws)

I clearly cited that the HN guideline was from Submissions and provided the link.

I also clearly expressed the opinion that given the displayed URL was truncated, that maybe, it would be prudent to post a warning [PDF].

I wonder what's going on here with the v3 tor site traffic

https://metrics.torproject.org/hidserv-rend-v3-relayed-cells...

It's probably related to a DDOS

https://status.torproject.org/issues/2022-06-09-network-ddos...

Anyone know how and why the start of covid relates to an increase in unique .onion addresses?

https://metrics.torproject.org/hidserv-dir-onions-seen.html?...

Unrelated. Spikes in new unique onion addresses are tied to ransomware groups, who have their victims use Tor to negotiate payments.

The Tor Project dropped support for tor v2 from their software in October, 2020. At that point in time there were still far more v2 sites and traffic than v3. Probably there were attempts to spin up a bunch of v3 stuff to make the forced drop of v2 support seem more reasonable.

How hard would it be to enumerate v3 addresses? Say I have a server and only want 'those with the address' to connect (forgetting for a moment that mutual TLS etc exists)

Am I the only one who runs tor node on an android OS? Looks like everyone is Linux or BSD

Reply on news.ycombinator.com