<html>
<head>
<style>
.sw_message P{margin:0px;padding:0px;}
.sw_message {FONT-SIZE: 12pt;FONT-FAMILY:Tahoma,Arial,Helvetica,sans-serif;background:white;}
.sw_message blockquote{margin-left:5px;padding-left:5px;border-left:2px solid #144fae;color: #144fae;}
.sw_message blockquote blockquote{border-left:2px solid #006312;color: #006312;}
.sw_message blockquote blockquote blockquote{border-left:2px solid #8e5656;color: #8e5656;}
.sw_message blockquote blockquote blockquote blockquote{border-left:2px solid #888;color: #888;}
</style>
</head>
<body class="sw_message">
<div> I have something to add to this.<br><br>I'm a new relay operator, but not new to server hosting in general. People should be aware that some providers of vservers run their internal operations by using a large-capacity storage box for the disk storage, and separate hardware hosts which run the cpu/memory/operationals of the vservers. The disk storage is accessed by a private network and would tend to be reached by the servers through a manageable switch. At least on Linux platform, the protocol I have seen the hosts talk to the disk box with is NFS. The core of NFS is unencrypted.<br><br>In a server farm environment where one is keeping the traffic all on a private switch like that on private IP space, the operator would not tend to tunnel those host NFS connections over SSH. An operator is looking for speed and throughput in that environment, and SSH tunneling would decrease both. It is assumed that passing the traffic through the private switch isn't a meaningful security concern.<br><br>What that means to tor server operators is that if you're using a vserver where the internals are set up this way, the unencrypted contents of your disk are likely being exposed to a managed switch. That switch could potentially be used to examine or redirect traffic. This is a real concern, not a theoretical one. <br><br>Security procedures on the key handling should take into account this sort of situation, where it may exist.<br><br>(In my case I get to choose which way I want the vserver - and with that, I'll be taking my new tor server offline for a little while for a re-implementation :/ ).<br></div><div> </div><div id="editor_signature"></div><div>On Wednesday 21/08/2013 at 7:24 am, Moritz Bartl wrote: </div><blockquote type="cite">On 21.08.2013 11:56, Tony Xue wrote:<br><blockquote type="cite"> Is that those key files are only loaded when the Tor start and reload?<br> So could it be possible to decrypt the file before the start-up and<br> encrypt them again after the Tor start-up process is complete?<br></blockquote><br>The files are required only on startup of the relay, so you can keep<br>them stored wherever (offsite, in an encrypted container, ...), and<br>remove them from the live system after you start Tor.<br><br><a target="_blank" href="https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity">https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity</a><br><br>-- <br>Moritz Bartl<br><a target="_blank" href="https://www.torservers.net/">https://www.torservers.net/</a><br>_______________________________________________<br>tor-relays mailing list<br>tor-relays@lists.torproject.org<br><a target="_blank" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br></blockquote><br>
</body></html>