[tor-relays] Store key files in RAM

Tue Aug 27 14:52:49 UTC 2013

If you can execute shell commands directly from the
ram folder (ssh, sftp) and therefore pull files
straight into it with sftp, this seems exactly right.

It sounds like you'll only need the secure connection
on an occasional/rare basis. Imo don't try for an
always-on connection for that such as a vpn.

Whichever way you do, you'll want to pay attention
to where the important encryption keys reside. At
least in general (and maybe even specifically), we
know that encrypted data is being snatched off the
wire and retained. In the case of sshd, you would
want your sshd daemon keys to live on the machine
with the more-secure storage medium and use the
vserver as the client. For a vpn or similar you'd
need to look at exactly how it works and decide
if there is a right way and if so, what it is.

Hopefully the only thing you feel there is a need to
protect from is improper read access. If someone can
write to your vserver as root, that would be a Very Bad
Thing (TM).

Sorry about the strange/disjointed line feeds in my
first email btw, not sure why that happens. I'm
trying short lines now, seeing if it works better.
If you add linefeeds to what I wrote before where it
makes sense, it may be easier to read.

On Tuesday 27/08/2013 at 12:38 am, Tony Xue  wrote:
>
>
> Thanks for the instructions.
> So what if I set up an L2TP VPN connection from my server to my 
> computer at home which stores the keys and I download the file 
> directly into the RAM folder?
>
> The purpose is to avoid storing the file or let the file passing 
> through the local normal storage system on my vserver which could be 
> extremely insecure in this situation.
>
> So will any of these techniques you have described or I stated above 
> let my data passing through the local ROM storage system of the 
> vserver?
>
>
>
>>
>>
>> Date: Tue, 27 Aug 2013 00:14:36 -0400
>> From: tor at t-3.net
>> To: <tor-relays at lists.torproject.org>
>> Subject: Re: [tor-relays] Store key files in RAM
>> Message-ID: <521c27ac.570.f998d700.49849df at t-3.net>
>> Content-Type: text/plain; charset="us-ascii"; Format="flowed"
>>
>> IMO cut and paste in the situation you're describing is not the
>> perfect way. Better way would be:
>>
>> Have a secure linux machine running an sshd at your home (or another
>> physically-controlled location?).
>> Close off iptables and ip6tables for inbound sshd except for your
>> vserver's IP
>> (hint: "ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_4096_key -b 4096"
>> (don't put a password when it asks))
>> and edit sshd_config to point it to the new key. Also in the config,
>> force your local sshd
>> server to insist upon only using these 2 ciphers ("Ciphers
>> aes256-ctr,aes256-cbc").
>> Restart the local sshd (maybe "service sshd restart") and verify that
>> you can NOT connect
>> from the vserver to the home box using a different cipher (ssh -l
>> someuser -c aes128-ctr your.home.ip.here).
>> A test ssh connection without the "-c aes128-ctr" should work, the one
>> with it should fail.
>>
>> You would do transfers of important files to and from the vserver via
>> an 'sftp' session which you start
>> from your vserver, and you are connecting into your home machine (sftp
>> someuser at your.home.ip.here).
>> Don't make the connection in the reverse direction, you can push and
>> pull files with the one. And don't
>> let anyone steal your ssh_host_rsa_4096_key off the home box. (could
>> even shred/delete/regenerate it
>> now and then). In general, turn off the home sshd when you aren't
>> using it.
>>
>> The above setup should be pretty good in terms of the network transfer
>> if the data hasn't already been
>> compromised, of course. The certainty that it hasn't been is not
>> necessarily guaranteed if it's already
>> been thrown through a network card in a less-solid way, such as the
>> contents having been viewed
>> via 'cat', 'nano', etc. via a connection in the 'wrong' direction.
>>
>> If you are deleting files from your vserver's hard drive after copying
>> them out for backup, try doing
>> "shred" on the file first, and then "rm". It may help do the deletion
>> better, depending upon how your vserver
>> hosting is set up.
>>
>>
>>
>>
>>
>> On Monday 26/08/2013 at 10:53 pm, Tony Xue  wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi,
>>>
>>> I have been discovering simple and secure way of protecting the Tor
>> > key files recently, in order to achieve the safety of the keys on 
>> VPS.
>>>
>> > So I created a folder on Linux called /tor and it is stored in the 
>> RAM
>>> file system. I put my key file into that folder and link it back to
>>> the data directory folder of Tor. I also backed up the key files in
>> > case my server need to be restarted and the RAM would be cleaned up. 
>> I
>>> left the key in RAM for some undesired failures, errors or
>>> configuration which need to restart the Tor software.
>>>
>> > If the server gets down, I would probably do the simple cut and 
>> paste
>> > in the SSH client to restore my key files. Or in a higher level way 
>> if
>>> cut&paste is not safe enough.
>>>
>> > I am not sure whether this is a good way to  protect my key files on 
>> a
>>> VPS. Does anyone have any comment on that or a better way?
>>>
>>>
>>> Tony
>>> _______________________________________________
>>> tor-relays mailing list
>>> tor-relays at lists.torproject.org
>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>>
>>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20130827/4debf599/attachment-0001.html>