
Tor: 1100 relays still run end-of-life tor versions - bcaa7f3a8bbc
https://lists.torproject.org/pipermail/tor-relays/2018-May/015124.html
======
coolspot
Maybe feds don’t want to upgrade their vast cloud of Tor nodes just yet [1][2]

1 - [https://blog.torproject.org/tor-security-advisory-relay-
earl...](https://blog.torproject.org/tor-security-advisory-relay-early-
traffic-confirmation-attack)

2 - [https://arstechnica.com/information-
technology/2014/07/activ...](https://arstechnica.com/information-
technology/2014/07/active-attack-on-tor-network-tried-to-decloak-users-for-
five-months/)

~~~
John_KZ
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.

~~~
Santosh83
I'm just throwing an idea out here. It is often stated that running Tor exit
nodes is both costly and dangerous. For understandable reasons. Yet the
network needs more such nodes, to defeat the scenario of one powerful entity
operating hundreds of exit nodes. It would be nice if even ordinary Tor users
can run transient exit nodes. Now as it stands, nobody will do it. So why not
change the functionality of Tor such that it becomes possible for a user to
operate an exit node for a whitelisted list of sites (either based on IP or
domain names) that they are willing to funnel traffic for? It's still better
than giving up and letting a majority of exit nodes be controlled by state
actors and other powerful entities right? Serving traffic only for a set of
white-listed endpoints can considerably reduce the risk of running afoul of
local law enforcement.

I realise this effectively cripples Tor, but normal "uncensored" exit nodes
can still operate, by those willing to run them.

~~~
zingmars
I've seen this idea thrown around in Tor mailing lists as well.

The developers basically replied that while they're not happy about how Tor is
used by some people, if they started censoring some things, they would
eventually be required to censor others. At that point, what is really the
point of Tor - just chain some VPNs together.

~~~
Santosh83
The point would be the stronger anonymity offered by Tor, whereas with VPNs,
you're basically at the mercy of the service providers not to keep logs. Also
the developers needn't censor anything but merely build in a mechanism that
individual node operators can use or not as they see fit. Like adblock lists,
the lists themselves would presumably be made and circulated by interested
individuals, and nothing to do with Tor devs.

Anyway, thinking further, I realised even a whitelist can be bypassed in
various ways to do illegal stuff, so you'd still need to be quite prepared and
legally informed before running an Exit node. :-(

------
f2n
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)

~~~
OrangeTux
Is it hard to create a Tor node? And is it juridically safe to be an owner of
a Tor node?

~~~
exikyut
It's very easy, but yes, you cannot control what data exits it.

I'm just as curious as you what the GP's internet setup looks like.

~~~
strken
The GP didn't necessarily say he was running an exit relay, only that he was
running a relay of some kind. As far as I know it's a lot less perilous to run
a middle relay.

------
forapurpose
> 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.

~~~
fyfy18
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.

~~~
cyphar
Tor routes more packets through "trusted" nodes that have a history of being
fast, and so on. I wonder whether an automated kill switch would affect those
statistics (resulting in possibly lower overall network bandwidth because the
trust level of most nodes would be worse).

~~~
Xophmeister
If trust is quantified by node, then surely it could just be reduced as a
function of outdatedness.

------
maerF0x0
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.

For example the 1213 days of presumably no updates by f2n (mentioned in
another comment:
[https://news.ycombinator.com/item?id=17150526](https://news.ycombinator.com/item?id=17150526)
)

~~~
cesarb
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.)

------
qop
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?

~~~
bcaa7f3a8bbc
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.

------
bcaa7f3a8bbc
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](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
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.

~~~
yjftsjthsd-h
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?

~~~
operandroid
So, _TOR_ works in this way, but some other hypothetical ideal system would
never work this way.

An ideal system would operate in such a way that reading an ordinary public
resource requires no single peer. If I want to simply read a wikipedia page,
no single individual should be capable of knowing that I requested that page,
and be tasked with the entire responsibility of proxying my request. No single
peer should even know that a wikipedia page is what I asked for, who I asked
for content from, or where I've been and what I've been doing.

Right now HTTPS offers content privacy, but no meta data privacy. TOR offers a
degree of meta data privacy, but no guarantee of content privacy. Even with
the two combined, the TOR exit node can still understand that _someone_ logged
into Gmail, and _someone_ probably tried to send a message with an overall
length of ~2MB.

With a strategic vantage point, enough facts could become evident, that TOR
would fail to offer enough protection, and still out someone trying to
accomplish a secret task with TOR.

It should be possible to provide both content privacy and meta data privacy,
so that my solid gold widget factory plans are mailed safely to my vacation
home, and no one knows that I mailed them to myself, that I mailed anything at
all, or what I mailed if that's what I was doing.

I don't care about how " _it_ " works, if TOR can only suck one way, and can't
not suck some other way. I want something that doesn't suck. I already said I
don't want TOR. TOR doesn't need to be something else. It just needs to stop
telling people it's something better than it actually is.

~~~
eklitzke
You can't magically make bridging to insecure services work in a secure way.
If you want to use Tor to bridge to unencrypted HTTP, at some point someone
needs to actually make an unencrypted HTTP request. And likewise for HTTPS
requests.

HTTP is a stateless protocol, which is why what you're describing is not
possible. You could design a protocol that let you split up requests in the
manner you describe, but that protocol would not be HTTP.

~~~
operandroid
One can obfuscate an extremely live distributed, obfuscated cache that mirrors
public resources, and that's not magic.

Just because you have trouble imagining the implementation of such a thing
doesn't mean I do, and doesn't make it impossible.

