[tor-relays] OS diversity of tor relays (was Re: Relay uptime versus outdated Tor version)

George george at queair.net
Wed Aug 23 00:10:00 UTC 2017


Jonathan Proulx:
> 
> How this got off into TorBrowser puzzles me.  Presumably the goal for
> clients is to reach them where they are.  Certainly providing a
> diversity of clients is a "good goal" but beyon dreaching more users I
> fail to see how it helps the network writ large. I suppose indvitual
> users woudl be mroe secure with a wider array of clients available,
> but that's generally true of the Windows monculture in desktop
> computers. And as we shift to Android moblie devices as people primary
> internet connection many of those issues will likely follow, but I
> digress...

With TB as a client, I just mentioned the development end in an earlier
email. There's certainly more to it.

There are certainly weaknesses in a client monoculture that differs from
the network/node side on some levels, as the client software is in some
chases the user base.

But it always seem to me users sometimes use the OS that provide the
applications they want. TB matters insofar as one of those applications,
I tend to think.

On the whole, one needs to consider that the same single vulnerability
that weakens an OS on the network level could also affect the desktop.

> 
> 
> For relay diversity it's more obvious.  If you can sabotage 93.6% of
> the band width because a Linux specific bug either in TOR or just the
> OS that's a huge problem (from
> https://torbsd.github.io/oostats/relays-bw-by-os.txt, sorry I forget
> who to credit but if you read the thread you will see...).

And if you compromise the vast majority of desktop users, you don't just
implicate those users with the vulnerability, but a big drop in the
majority client OS would mean the crowd, so desperately needed for an
anonymity solution, thins out.

Credit? Yes... us at TDP (https://torbsd.github.io/)

> 
> I run
> https://atlas.torproject.org/#details/A53C46F5B157DD83366D45A8E99A244934A14C46
> which in it's current incarnation is FreeBSD 11 since January 2017 or
> so.  Though for most of it's life had been Debian or Ubuntu.
> 
> I'm definitely a "Linux Weenie" specifically of the Debian family so I
> enjoy what "unattended upgrades" can do interms of when and what you
> automatically upgrade and when/if to reboot if needed, but really the
> 98% of that that really matters you can do with a small shell script +
> cron.  Installing TOR isn't really appreciably harder either "pkg
> install tor" is just as easy as "apt install tor" for people who want
> to live in a packed rather than source world.  So I don't think the
> complecity barrier is real (though the perception of one may be a
> deterrent).
> 

As I stated earlier, the tools for FreeBSD and OpenBSD are there.

utilities like syspatch on OpenBSD stable can be put into a regular cron
job.

Same with pkg and freebsd-update on FreeBSD.

Note the BSDs provide daily/weekly/monthly emails by default, and any
notifications are already or could easily be integrated into those emails.

> Looking at
> https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Public_servers_on_the_Internet
> it seems TOR relay OS's while skewed toward Linux and away from
> Windows aren't that far off from at least soem studies of "Internet
> based servers' market share". I debate the accuracy of these in
> general but within some largish margin of error they are probably not
> untrue.
> 
> Monoculture isn't just a TOR problem.  I think we should advocate for
> it but I don't think we can solve it just in a TOR context.  So yes if
> you run relays go learn some underserver Operating Systems the BSDs
> are a little weird at first coming from Linux but you're clever you'll
> manage or maybe go way out there to one of the Firefly (OpenSolaris)
> variants...but diversify all the things nto just TOR.
> 

I'm a little confused by that paragraph, but I do think it's possible to
rectify the situation to a large extent.  A large number of firms use
BSD in their infrastructure or code (WhatsApp, NetFlix, Juniper...).
What if some started to run relays or bridges? What if there was a list
of BSD virtual private server firms that allowed Tor relays/bridges? I
can go on and on, but those are the type of approaches we are trying at TDP.

Giving up on network diversity for Tor is essentially allowing it to
remain vulnerable to a single kernel weakness.

On a side note, there's a reason why computing systems tend to
monocultures. They are easier to build, maintain and develop on. It's
more efficient to make the same exact widget out of a machine than it is
to make six variations. That doesn't apply to the many current and
potential relays operators out there.

g


-- 



5F77 765E 40D6 5340 A0F5 3401 4997 FF11 A86F 44E2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20170823/a7f57792/attachment.sig>


More information about the tor-relays mailing list