[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-relays] [tor-talk] Platform diversity in Tor network [was: OpenBSD doc/TUNING]

>> I'd agree simply because Windows presents a much larger attack surface. The
>> amount of code running on a minimal Unix installation plus Tor is a lot less
>> than a Windows system, especially network facing code.
> ...
> Running code, or network accessible code?  Either way I don't see how
> you came to that calculation.  'Minimal' Unix + Tor + SSH restricted
> by SSH Key vs 'Minimal' Windows + Tor + RDP restricted by Client
> Certificate.  I also don't know what you mean by 'minimal' as very few
> ...
> I think a Windows Server, properly configured, is roughly as secure as
> a properly configured Linux Server.
> ...
> I think there have been more bugs that result in RCE on production
> Linux servers running SSH and a webserver in the past 4 years than
> there have been in production Windows servers running RDP and IIS.
> ...
> I think if you're pointing fingers at China and the NSA, you should
> assume they have RCE in both Windows and Linux.
> ...
> I think running relays on Windows Servers is no worse than running
> relays on Linux Servers, and therefore it is good to do, because it
> adds diversity to the network.

Attack surface on a well adminned relay comes down to three things:
- Network stack itself (kernel)
- Daemon software itself (tor + remote admin)
- Their respective use of other kernel/library/shell provided resources.

I might suggest the current proportion of Windows to Linux is
roughly ideal. This is primarily because, all other things set equal
at 'minimal' (= tor + remote admin), good adminning, and good
control of corporate secrets (or moles)... Windows still has one
huge strategic weakness at that point... the magic packet.
It's the whole binary vs. opensource argument. So essentially,
the correct ratio of the two might be the odds you place that
a binary OS has a magic packet. Today's node count shows
73% to opensource platforms. I'd suspect 73% is about where
a lot of analysts might bet on Windows being magical, whether
by/for the NSA, or any other reason or source.

(Remember this...
 https://en.wikipedia.org/wiki/NSAKEY
That was just from running 'strings'. Good luck trolling all of
Windows with a disassembler... a nice fat payoff if you do. And
the number of disassembling vs. opensource auditors is probably
even more heavily skewed. And Windows is 'trusted' by buyers,
nor can you replicate their binaries from any 'source code sharing
agreements'. Then it's Patch Tuesday again... so it could be no
one has or ever will disassemble audit it. So odds end up being
pitched instead. And for many applications, that's good enough.)

The real problem below is the 96% allocation of opensource to
Linux and 4% to Other opensource. That's something that should
be fixed. For these purposes, it doesn't matter which BSD/Other you
pick... once you get the security odds there back towards
say 50:50 Linux:Other, then you can debate userland and relative
security amongst them all you want.

Here's some links to get you started, including two other
main branches of the Unix Kernel family tree at the bottom...

5939 Linux
1591 Windows
 173 FreeBSD http://www.freebsd.org/
  56 Darwin
  44 OpenBSD http://www.openbsd.org/
   7 NetBSD http://netbsd.org/
   6 SunOS
   4 Bitrig https://www.bitrig.org/
   2 GNU/kFreeBSD https://www.debian.org/ports/kfreebsd-gnu/
   2 DragonFly http://www.dragonflybsd.org/
   0 Illumos (OpenSolaris) http://wiki.illumos.org/display/illumos/Distributions
   0 Minix http://www.minix3.org/

Official metrics...
https://metrics.torproject.org/network.html

Someone should really do an analysis of platform vs. exit bandwidth
as well. Anyone?

Also, isn't there some project out there that is counting the historical
number of kernel bugs+severity per OS over time?

[To cpunks to cover all the other volunteer node based networks
out there that could benefit from tuning their platform ratios.]
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays