On 5 November 2014 11:55, Libertas <liber...@mykolab.com> wrote: > I hope I don't sound too pompous saying this, but I really don't think > relays should run on Windows. Windows is the primary target of > weaponized and general exploits,
Windows desktops, yes. Where users are browsing websites on IE, with plugins and Flash Player and old versions of Adobe Reader and Java. Windows Servers have none of those things, most importantly users fiddling around on them regularly. > and it's less secure than a properly > configured Unix distribution. Are you comparing a Linux Server to a Windows Desktop? Or a Linux Server to a Windows Server? If it's the latter - I'm going to disagree and try and provide supporting evidence... > This is especially relevant with potential adversaries like the > Chinese government, who can buy Windows exploits > that can't be > prevented by user configuration, I'm confused by this - what bugs are you talking about? The only bugs that 'can't be prevented by user configuration' would be in the networking stack. And that applies just as much to Linux as it does to Windows. Now yes, you can patch your kernel yourself on Linux, which you can't on Windows - but when Shellshock came out, were you going into Bash to patch it yourself? Or were you waiting for bash itself to provide patches? Also, they can't buy Linux exploits? > and can't be recognized by public > auditors because of the closed source code. That's true, it's definitely easier to audit open source than Windows. But from a "is this bug serious" point of view - MSFT gives pretty good insight into what they're patching and the impact of it. "Public Auditors" (like myself) have a good deal of confidence in understanding risk based on this information. For example [0] [1] last month, You've got: 1 RCE in IE 1 RCE in .Net WebApps with understanding about how to determine if you're vulnerable 3 CE if you phish a user into opening a document or browsing a website (two of them in office, not windows) 1 UXSS if you phish someone 1 Local EOP in default config 1 Local EOP if it's not a default configuration None of these are realistically exploitable on a Windows Server. On a tor relay on a Windows Server you've got (maybe) IIS running, the Windows networking stack, and maybe but usually not RDP open to the world. I can only think of two or three bugs in the last 3 years that _could_ have been exploitable in that configuration. The weak point is (as usual) whatever random web application the user has running on the relay. (Ideally, none. But I expect most relays that run on servers pull double duty.) > Market *nix exploits also > exist, but (IIRC) they're much rarer and less expensive. I'm not sure 'rarer' and 'less expensive' go together, did you mean more expensive? (I'll assume yes.) I don't like arguing economics because I don't think either of us buys or sells exploits, so everything is just hearsay. But it's definitely easier to write exploits for open source code than it is closed source. That would push the price down. They're also more common. I can point to several remotely exploitable bugs in Linux-land. I have a hard time pointing to equivalent bugs in the equivalent Windows subsystem. Big bugs are remotely exploitable, and they get remotely exploited, and have easy-to-use attack tools - regardless of platform. So going by that yardstick: nginx RCE (2013) vs IIS RCE (any?) several rails RCEs vs .Net Framework RCE (can't think of any, but maybe one or two somewhere) OpenSSL, which runs on Windows in Tor also, but I'm going to count as 'Linux' because Windows has its own SSL stack: SRTP DoS last month, Heartbleed, EarlyCCS vs MSFT SSL stack bugs (can't think of any) Linux networking stack (can't think of any) vs Windows (there was that one bug a couple years ago, can't recall all the details, but iirc no one managed to make an exploit out of it) OpenSSH (none) vs RDP (again, one a couple years ago, but it required open RDP, without Client Certificates, and while I think someone may have pulled off an exploit, I don't think it was public.) > It's possible that I'm wrong, though. Let me know if Windows is more > secure than I think. I think it is more secure than you think. On 5 November 2014 12:20, Niklas Kielblock <nik...@spiderschwe.in> wrote: > 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 people actually configure their kernels themselves - most use debian/ubuntu. On the face, I'm not thinking Ubuntu is any more 'minimal' than Windows. I'm going off of my experience, which comes across in the form of some data here, some data there. It's not comprehensive, by any means. It's a subjective argument at its core, but I'm trying to bring out why I think the way I do. I think a Windows Server, properly configured, is roughly as secure as a properly configured Linux Server. (I think OpenBSD probably beats both of them, but I have very little experience with OpenBSD.) 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. I think diversity is a good thing, because it reduces the likelihood that a bug (security or not) will result in a disruption for a majority of the network at once. -tom [0] http://blogs.technet.com/b/msrc/ [1] https://technet.microsoft.com/library/security/ms14-oct _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays