One of the biggest technical and security issues in the Tor network is that the full list of nodes can be easily and quickly retrieved—in seconds, with a single click—just like querying a DHT list. This has been pointed out by many users, yet the developers seem to have no plan to fix it.
There is a simple potential solution: distribute the node listing across specific nodes which only publish aggregated information, such as country of origin and nickname, without exposing the IP address. These listing nodes should also be protected by bot mitigation systems, making large-scale scanning infeasible. This protection should focus particularly on entry and exit nodes.
Furthermore, users who run entry or exit nodes should only publish their status in a limited, anonymized way. There’s a significant difference between scanning the entire Tor network in seconds versus needing days or even weeks to do so.
Additional suggestions:
Introduce temporary, short-lived nodes operated by users.
Once this issue is addressed, the Tor Browser could offer a simple mode that lets users occasionally act as a lightweight relay or other node type (with consent).
Why this is a serious problem:
Websites can easily block the entire Tor network by banning all known Exit Nodes. This leads to 100% blocking—making Tor unusable regardless of what countermeasures you take. In some cases, Tor users are permanently banned from accounts if detected, not just temporarily restricted. Even though bridges exist for entry points, ISPs face the same issue, as they can also see all public nodes.
ISPs can identify and block all entry nodes, and worse, they can manipulate routing by allowing only traffic through nodes they control. Even with triple-layer encryption, each node knows its own encryption key. If all relays in a circuit are controlled by a single entity, decryption and deanonymization becomes trivial. Even without decryption, such manipulation can make a user’s path trackable.
People running Tor nodes are being punished, as their IPs end up on blocklists, denying them access to many online services. This discourages well-meaning operators, leaving a larger proportion of malicious node operators behind.
Additional Proposal:
There should be an easy way to route traffic through a VPN after the exit node—not just before connecting to Tor. VPN-before-Tor doesn’t help with website-level blocking, and using VPNs alone is not anonymous or trustworthy.
Due to Relay and bridges exposing IP addresses, ISPs and GFW (Great Firewall) web crawlers detect these IPs and add them to blacklists. Even if new Tor Relay Operators join the Tor network, they won’t last a day. In China, only the WebTunnel bridge is available for 24 hours; after that, it becomes ineffective and is blocked by the ISP’s GFW.
If the IP-addresses wouldn’t be public, how should the Tor client be able to build a circuit? Without the public network consensus the entry node would have no idea to which relay it should forward the package to.
The network consensus being so easily accessible ensures transparency and integrity. Each user can verify it’s circuit without trusting a black-box central authority.
This are entry nodes which are not publicly listed to mitigate the issues you listed above.
Websites can easily block the entire Tor network by banning all known Exit Nodes.
This is true, but I think it’s a hard issue to solve since once the connection leaves the exit node it’s out of Tor’s control.
Introduce temporary, short-lived nodes operated by users.
This is an interesting proposal. And maybe something to consider. But a lot of short-lived nodes would also mean a lot of untrustworthy nodes. The lifetime of a relay is an indicator for stability and trustworthiness.
There should be an easy way to route traffic through a VPN after the exit node
Interesting, but then the exit node would have to support it.
How are you going to encrypt traffic to send through 3 relay (how Tor works) if you don’t know the IP of every of these relays? Or are you suggesting DAs (directory authorities) take part in user’s circuit creation?
They can make sure only those entry nodes they control can be accessed, but how are they going to select the 2nd and 3rd nodes? They can’t control the node info (concensus) DAs feed clients (it’s encrypted so no way to tamper with it). And if the entry nodes they controlled tries to prevent connection to any nodes that wasn’t controlled by the same adversary, these entry nodes will basically become unusable [1] and ejected by Tor network health team in no time.
There is not. To optimize network throughput, most VPNs uses UDP as their underlying transport layer protocol (because TCP-over-TCP sucks in performance ). And Tor only supports TCP connections. Therefore for many such VPNs it’s impossible to route them over Tor, unless you do a wrap-unwrap on both client and server side, which then requires you to setup your own VPN server.
[1] because circuit is created based on concensus on client side and decided before 1st hop connection was made, it’s impossible to make sure a vanilla tor client will create circuits that satisfies client-entry node A(adversary-controlled)-relay node B(adversary-controlled)-exit node C(adversary-controlled)
The full list of Tor network nodes can be read out in seconds. On top of that, the problem is that this list is officially published as well. This allows websites to block them easily they can identify all exit nodes completely and within seconds. On such sites, only VPN services still work. For this to work in real time and at high speed, the entire network map needs to be read continuously. The situation is getting worse; a few years ago, this was not an issue. But now, **there are far too many websites that completely block access from the Tor network.**One possible solution is to segregate nodes into separate groups to prevent bots from quickly reading the whole network. Instead of one large pool, there would be several smaller circles, and each circle would function like a library or more accurately, like a torrent tracker. In this analogy, the “books” are the Tor nodes, and only those who pass a test gain access to the IP addresses of the nodes stored in that specific “library.” The libraries themselves only store the IP addresses of the nodes information that is public but before someone passes the test, they can only see the country code and the node name. Once they pass, they receive the rest of the connection data. The short version is that there needs to be a barrier to prevent the entire network from being quickly scanned, because that makes it pointless. And it’s no longer just the big, professional Chinese firewalls Tor. But on any website that blocks the Tor network, the service becomes completely unusable. Another solution would be to use a VPN after the Exit Node, since VPNs currently can’t be filtered as effectively as the Tor network. Some VPN IP addresses might be blocked a small portion of the network but not the whole service. The sites I mentioned now only work with VPNs, and on many of them, any account accessed via Tor becomes permanently unusable; in other words, the block is final, especially on larger forums. This means that no matter what network you log in from, the account will not become temporarily but permanently unusable. At this point, the situation is such that in its current form, the software could quickly become unusable. An artificial intelligence system which is being developed more and more intensively now can filter this traffic without any difficulty. Even email services now want to know everything about their users; they require phone verification, and during registration, they completely block access from the Tor network. There are almost no email services left where registration still works through Tor. For websites, anyone who wants to block the Tor network are block the full network. And it doesn’t matter what exit node you use, because you can’t get around it. A few years ago, a few ExitNodes may have been blocked, but there was no complete blocking of the network from a website perspective.
It’s because there are malicious actors on the Tor Network too. For the web service operators it’s not even worth it to send abuse complaints to the exit node operators, because exit node operators don’t know who this malicious actors are and cannot stop them from doing malicious things. So the web service operators choose the easy way and block the exit nodes completely.
It’s those websites that decided to discriminate against Tor users by banning accounts or blocking them totally, instead of deploying actually helpful account security measures, Tor didn’t “make your account unusable”, those websites and services did. You may find it tempting to blame Tor for getting your accounts banned or making it impossible to use certain sites, but that’s not going to look good on you.