Is there anyone that still believes TOR will protect him from state actors?
It's nice that people still run exit nodes, but it's so expensive and dangerous that you cannot expect a satisfactory number of nodes to be run for moral reasons and not for monetary/surveillance ones.
Also since most of the nodes are run on VM instances, a few companies could potentially recover all the routing and keys from the servers RAM if they feel like it. They're not going to do it for the average joe, but things like the Patriot act and it's European equivalents make sure intelligence agencies can do it if they want.
Thanks for posting, turns out one of these was mine. I forgot that it existed. 1213 days of uptime, still running Debian Wheezy (don't worry, i'm bringing it up to date now)
Thanks for running a Tor relay, even better, Tor relays! Please consider to check the right sidebar for new versions on https://blog.torproject.org/, add Debian repos from Tor Project instead of using default repo, and read [tor-relays]* mailing list routinely. It's a fun read comparable to Hacker News, well, sometimes.
> We encourage everyone to configure their relays to do updates automatically
I understand the general security benefits of automatic updates, but on something with as big a target on its back as Tor, isn't it asking for trouble? An attacker could poison an update and make vulnerable the entire network for as long as it takes for the Tor Project to discover the problem and patch it.
How does the security professional balance such issues? I can imagine mitigating the risk with rolling updates, but the 0-days aren't patched immediately.
How about if the node just shutdown after X period of no updates? It would be inconvenient for the admin and users specifically using that node, but would be a win for overall network security.
It could still expose a vulnerability meaning someone could kill the whole network, but that’s better than compromising it.
If they're not updating their main software, what makes us think they're patching the host? It makes me wonder what percent of those 1100 are compromised.
The attack surface matters. If the only exposed services are tor and sshd with public key authentication, one would need a vulnerability in either to compromise the host. How long ago was the last RCE on pre-authentication sshd?
(Of course, the lack of patches means that, once someone gets a RCE on either of these daemons, it's probably game over for the host.)
Are they encouraged in their languages? How many of those relays are run by ESL operators? Maybe internationalization could improve the adoption speed or update speed or whatever you call that metric.
Do these operators actually even know they are EOL'd?
Not at all. They don't. Once the relays are up, many people simply forgot their existence at all, except they pay the bill. Just like many people's email server... And it's hard to contract many of them due to its decentralized nature, and most people don't actively follow [tor-relays] mailing list.
I'm the submitter. I see there is much misunderstanding and misinformation of Tor relays, even on Hacker News. I'm not a Tor dev, but I've been running a node for years, so I'd guess I somewhat have an authoritative opinion on this issue. The issue is simple and no conspiracy theory required.
1. This report mainly deals with Tor relays. A Tor relay is not a Tor Exit (well, you can argue Exit is a special type of relay). Tor relays can be run on all servers, optimally, with fixed IP address, bandwidth >10Mbps (do set appropriate bandwidth limit in /etc/torrc, or it burns all your bandwidth), anyone can help the network by running one. Tor relays only generate encrypted traffic to other Tor relays, and risk of running one relay is even lower than, let's say, a BitTorrent client. All you need is 5 lines of /etc/torrc, but better to tune the networking stack first.
2. Tor Project does not run any Tor nodes(x), most operators are enthusiasts, others are NGOs and privacy service providers doing a charity. If you read the [tor-relays] mailing list, you can see the people are just like those who run their personal email servers. Enthusiasts consist the people who are both networking hobbyist (understand networking, BGP, also familiar with network/server providers(x) around the world, for getting the maximum bandwidth, OVH, anyone?), and privacy enthusiasts (who know what is public key cryptography, uses GnuPG, follow security news, etc). There are lots of networking hobbyist (okay, not too many), and privacy enthusiasts. But only those people who have BOTH the hobbies, would eventually find their way to the [tor-relays] community, a small number.
2a. You see, the major obstacle of the growth is lack of publicity, and misunderstanding of Tor relays/exits. In 2014, EFF started a "Tor Challenge", and resulted a surge of 1,700 new nodes. Most of the nodes are STILL ONLINE (and probably being forgotten and hence outdated...). The speed of the Tor network has increased significantly due to the growth of interest since 2013, but more relays are always needed, currently there are less than 7000 nodes. Do you want to run? Start from https://trac.torproject.org/projects/tor/wiki/TorRelayGuide
3. Tor almost uses a rolling release model. The development pace is fast (but developers are not too many, need more), you can see Alpha versions being released almost every week. And they are more like a "mainline" version rather than a "alpha" version, and most of the time these "alpha" is already stable enough for casual uses. After the next alpha series is released, the current alpha is promoted to the "stable" series. This release model has some problems with traditional Linux/UNIX distros. For example, the Tor version in Debian (not Tor's) and OpenBSD's official repository is ALWAYS outdated by an entire series, since it has been freezed since distro's release date. Recently Tor just made another release, renders lots of current server being completely outdated.
4. Running a Tor Exit generally requires more cares of the servers, routinely respond to abuse mails, diagnose server problems and optimize performance. I haven't check, but I guess only a small percentage of these outdated versions are Exit.
4a. Running a relay is easy, most relay operators set up their servers in a fire-and-forgot basis, the servers are barely being touched anymore, once it has been configured and running correctly. Once the relays are up, many people simply forgot their existence at all, except they pay the bill. Just like many people's email server... And it's hard to contract many of them due to its decentralized nature, and most people don't actively follow [tor-relays] mailing list. Many careless operators also don't actively check their contract emails. Few of them even don't bother to leave contract information, or name their nodes (default: i_didnt_edit_config)...
5. Because Tor releases often, occasionally some people don't want to deploy updates until the next major maintenance reboot, because they don't want to lose the high uptime and large traffic they've waited to get for months (for new nodes, Tor traffic reaches to the maximum only after 3 weeks of continuous operation)...
TLDR, I guess automatic update is the solution, since the update is already signed. Also, we may need to make running Tor relay a more interactive process.
(x) Even authoritative servers are contributed to well-known members of the developer community, in a individual basis.
(x) But don't use OVH for your new Tor relays, it's already the largest network of Tor nodes thanks to the cheap bandwidth.
Given the project's goals, TOR cannot operate release versioning, interoperability, and backward compatibility like a "normal" open source project.
Old versions need to be something akin to a burnable one-time-pad, that gets burnt when deemed more vulnerable than it's up-versioned, more secure replacement.
In many ways, this kind of sucks as an idea, but in pragmatic terms, I just really wouldn't want idiots relaying traffic I'd feel paranoid about, in ways that'd cause me to lose sleep at night.
That said, I don't even think the routing protocol has honest merit. The idea that you should place an all-consuming degree of trust in the honor system surrounding exit node operators having total access to plain-text traffic is beyond-the-pale in its stupidity.
No one can field a satisfactory answer for me, regarding why it's okay that exit node operators have access to plain-text traffic.
Oh, because traffic analysis
is hard, and most exit node
operators are amateur hobbyists.
or maybe
That's just the way it works.
You can't make TOR work any
other way.
That's basically what I hear. It's the HAM radio excuse put another way. HAM radio has utility, bause we think it's neat. You don't need to worry, because it's free for everyone to use.
Okay, but that's not what TOR is trying to accomplish.
Well... That is how it works. Either traffic stays on tor (hidden service) or it leaves and the exit node can see it. This is a good reason to use HTTPS. How would you like it to work?
I agree that exit nodes are inherently bad and avoid it. but it is a good solution that is indeed akin to the utility HAM operators provide. I fail to see why it's not.
[+] [-] coolspot|7 years ago|reply
1 - https://blog.torproject.org/tor-security-advisory-relay-earl...
2 - https://arstechnica.com/information-technology/2014/07/activ...
[+] [-] John_KZ|7 years ago|reply
It's nice that people still run exit nodes, but it's so expensive and dangerous that you cannot expect a satisfactory number of nodes to be run for moral reasons and not for monetary/surveillance ones.
Also since most of the nodes are run on VM instances, a few companies could potentially recover all the routing and keys from the servers RAM if they feel like it. They're not going to do it for the average joe, but things like the Patriot act and it's European equivalents make sure intelligence agencies can do it if they want.
[+] [-] auslander|7 years ago|reply
Users pay its yearly fee via Bitcoin. Once a year.
Tor client authenticates to entry node with wallet ID. Node checks in blockchain that fee's been paid and forwards traffic.
Plus - clean nodes operated by trusted Tor project team.
Minus - experts need review that wallet checking is not a deal breaker. I have not really thought this through, just throwing ideas :))
[+] [-] f2n|7 years ago|reply
[+] [-] akerro|7 years ago|reply
https://github.com/v2tec/watchtower
[+] [-] bcaa7f3a8bbc|7 years ago|reply
* https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-re...
[+] [-] OrangeTux|7 years ago|reply
[+] [-] maeln|7 years ago|reply
[+] [-] penagwin|7 years ago|reply
[+] [-] forapurpose|7 years ago|reply
I understand the general security benefits of automatic updates, but on something with as big a target on its back as Tor, isn't it asking for trouble? An attacker could poison an update and make vulnerable the entire network for as long as it takes for the Tor Project to discover the problem and patch it.
How does the security professional balance such issues? I can imagine mitigating the risk with rolling updates, but the 0-days aren't patched immediately.
[+] [-] fyfy18|7 years ago|reply
It could still expose a vulnerability meaning someone could kill the whole network, but that’s better than compromising it.
[+] [-] maerF0x0|7 years ago|reply
For example the 1213 days of presumably no updates by f2n (mentioned in another comment: https://news.ycombinator.com/item?id=17150526 )
[+] [-] cesarb|7 years ago|reply
(Of course, the lack of patches means that, once someone gets a RCE on either of these daemons, it's probably game over for the host.)
[+] [-] qop|7 years ago|reply
Do these operators actually even know they are EOL'd?
[+] [-] bcaa7f3a8bbc|7 years ago|reply
[+] [-] bcaa7f3a8bbc|7 years ago|reply
1. This report mainly deals with Tor relays. A Tor relay is not a Tor Exit (well, you can argue Exit is a special type of relay). Tor relays can be run on all servers, optimally, with fixed IP address, bandwidth >10Mbps (do set appropriate bandwidth limit in /etc/torrc, or it burns all your bandwidth), anyone can help the network by running one. Tor relays only generate encrypted traffic to other Tor relays, and risk of running one relay is even lower than, let's say, a BitTorrent client. All you need is 5 lines of /etc/torrc, but better to tune the networking stack first.
2. Tor Project does not run any Tor nodes(x), most operators are enthusiasts, others are NGOs and privacy service providers doing a charity. If you read the [tor-relays] mailing list, you can see the people are just like those who run their personal email servers. Enthusiasts consist the people who are both networking hobbyist (understand networking, BGP, also familiar with network/server providers(x) around the world, for getting the maximum bandwidth, OVH, anyone?), and privacy enthusiasts (who know what is public key cryptography, uses GnuPG, follow security news, etc). There are lots of networking hobbyist (okay, not too many), and privacy enthusiasts. But only those people who have BOTH the hobbies, would eventually find their way to the [tor-relays] community, a small number.
2a. You see, the major obstacle of the growth is lack of publicity, and misunderstanding of Tor relays/exits. In 2014, EFF started a "Tor Challenge", and resulted a surge of 1,700 new nodes. Most of the nodes are STILL ONLINE (and probably being forgotten and hence outdated...). The speed of the Tor network has increased significantly due to the growth of interest since 2013, but more relays are always needed, currently there are less than 7000 nodes. Do you want to run? Start from https://trac.torproject.org/projects/tor/wiki/TorRelayGuide
3. Tor almost uses a rolling release model. The development pace is fast (but developers are not too many, need more), you can see Alpha versions being released almost every week. And they are more like a "mainline" version rather than a "alpha" version, and most of the time these "alpha" is already stable enough for casual uses. After the next alpha series is released, the current alpha is promoted to the "stable" series. This release model has some problems with traditional Linux/UNIX distros. For example, the Tor version in Debian (not Tor's) and OpenBSD's official repository is ALWAYS outdated by an entire series, since it has been freezed since distro's release date. Recently Tor just made another release, renders lots of current server being completely outdated.
4. Running a Tor Exit generally requires more cares of the servers, routinely respond to abuse mails, diagnose server problems and optimize performance. I haven't check, but I guess only a small percentage of these outdated versions are Exit.
4a. Running a relay is easy, most relay operators set up their servers in a fire-and-forgot basis, the servers are barely being touched anymore, once it has been configured and running correctly. Once the relays are up, many people simply forgot their existence at all, except they pay the bill. Just like many people's email server... And it's hard to contract many of them due to its decentralized nature, and most people don't actively follow [tor-relays] mailing list. Many careless operators also don't actively check their contract emails. Few of them even don't bother to leave contract information, or name their nodes (default: i_didnt_edit_config)...
5. Because Tor releases often, occasionally some people don't want to deploy updates until the next major maintenance reboot, because they don't want to lose the high uptime and large traffic they've waited to get for months (for new nodes, Tor traffic reaches to the maximum only after 3 weeks of continuous operation)...
TLDR, I guess automatic update is the solution, since the update is already signed. Also, we may need to make running Tor relay a more interactive process.
(x) Even authoritative servers are contributed to well-known members of the developer community, in a individual basis. (x) But don't use OVH for your new Tor relays, it's already the largest network of Tor nodes thanks to the cheap bandwidth.
[+] [-] operandroid|7 years ago|reply
Old versions need to be something akin to a burnable one-time-pad, that gets burnt when deemed more vulnerable than it's up-versioned, more secure replacement.
In many ways, this kind of sucks as an idea, but in pragmatic terms, I just really wouldn't want idiots relaying traffic I'd feel paranoid about, in ways that'd cause me to lose sleep at night.
That said, I don't even think the routing protocol has honest merit. The idea that you should place an all-consuming degree of trust in the honor system surrounding exit node operators having total access to plain-text traffic is beyond-the-pale in its stupidity.
No one can field a satisfactory answer for me, regarding why it's okay that exit node operators have access to plain-text traffic.
or maybe That's basically what I hear. It's the HAM radio excuse put another way. HAM radio has utility, bause we think it's neat. You don't need to worry, because it's free for everyone to use.Okay, but that's not what TOR is trying to accomplish.
[+] [-] yjftsjthsd-h|7 years ago|reply
[+] [-] gcb0|7 years ago|reply