Http server instead of own server?

[Zenny]

On Sun, Feb 17, 2013 at 8:23 PM, Cesare Bianchi <cesare at cesarebianchi.com>wrote:

> Thank you for your suggestions.
>
> I have been thinking about the security of my proposed solution, and I
> realized that there are many loopholes.
>
> Anyway, the solution you propose needs a mandos server running on some
> machine, and a static ip address. What I propose is to replace the
> mandos server with a public http server (possibly LAMP, possibly with
> virtual hosts).
> 1. The client uses a normal http get request sending a random generated
> (simmetric) key encrypted with its private key;
> (e.g. http://www.mymandos.com/pass.**php?k=asdfghjqwetyuio<http://www.mymandos.com/pass.php?k=asdfghjqwetyuio>
> ).
> 2. The http server decrypts the random key with the client's public key,
> then encrypts the luks key with the random key, and sends it back in the
> response;
> 3. The client decrypts the luks key with the random key, and uses it to
> unlock the disk.
>
> The luks key exists in clear only for some microseconds.
>
> Anyway, if somebody gets the initramfs of the computer, can easily run
> the mandos client from the command line, which would connect to the
> server, get the luks key and give it in clear to the user. Bye bye privacy.
>
> This is a problem inherent to the mandos system. I mean, anybody can get
> the luks key using the mandos client from command line, if the client
> can connect to the mandos server.
> Obviously, if both the mandos server and client are controlled by you,
> you can turn off the mandos server when somebody "steals" the client.
>
> I was also thinking of adding in the request some hash of something
> inherent to the initramfs, so if somebody "disassembles" the initramfs,
> the request made from command line would have a different hash, and the
> http server would give a different response (or no response at all). But
> the problem of the open source code is that the algoirthm is public, so
> the user could easily discover what is the "magic hash" and compute it
> for itself. Back to square 1.
>
> Probably I will use a much easier solution. An ssh daemon running in the
> initramfs, and an automatic connection to an openvpn server (or if I
> discover how, to a hamachi network). So at least I can decide if and
> when issue the luks key, connecting with ssh.
>

Thanks for sharing your thoughts.

In view of the TLS/SSL vulnerabilities still unresolved, this seems to be
the best option for now to embed dropbear in initramfs and then make an
automatic connection to an openvpn server, but the kind of remote control
that mandos client-server provides gets missing in this setup.


>
> Obviously, the user could make a sandbox with the initramfs and make me
> think I am giving the luks key to the real machine, while I am giving it
> to him, but with such a user, better give him directly the luks key!
>
> Hope that my reflections can be useful to other people, and thank you
> anyway,
>
> Cesare
>
>
>
> Il 13/02/2013 12:27, Teddy Hogeborn ha scritto:
>
>> Cesare Bianchi <kzar79 at gmail.com> writes:
>>
>>  I manage various (virtual) servers running in various clients'
>>> locations. The clients must not have direct access to the servers
>>> data, so I ecnrypted the disks. At the present time, I must physically
>>> go (or connect to the virtual host) if a server reboots.
>>>
>>> I wanted to install Mandos client on the servers, but it needs a
>>> Mandos server runnning in the network, and obviously this only adds
>>> complexity.
>>>
>>> So, is it possible to use some simple form of connection to the
>>> "Mandos server", for example with a public basic http server?
>>>
>>
>> Firstly, your setup is not secure.  Your clients can access the memory
>> of the virtual machines, where the keys to the encrypted disks are
>> stored.
>>
>> Secondly, the problem you want to solve does not need any source
>> changes; the code is written to be flexible enough to cover your use
>> case.  What you should do is four things:
>>
>> 1. Add "ip=dhcp" to the Linux kernel command line; do this by editing
>>     the GRUB_CMDLINE_LINUX_DEFAULT setting in your /etc/default/grub
>>     file; add "ip=dhcp" to the setting.  If DHCP is not available for the
>>     Mandos client systems, use the syntax "ip=1.1.1.2::1.1.1.1", where
>>     "1.1.1.2" is the client IP address and "1.1.1.1" is the local
>>     gateway.
>>
>> 2. Add, to the /etc/mandos/plugin-runner.conf file, this line:
>>
>> --options-for=mandos-client:--**connect=1.2.3.4:1234
>>
>>     Replace "1.2.3.4:1234" with the IP address and your chosen port of
>>     the Mandos server.
>>
>> 3. Run "update-initramfs -k all -u" to update the initramfs image.
>>
>> 4. Configure the Mandos server to use a specific port number by
>>     uncommenting and editing the "port" setting in /etc/mandos.conf on
>>     the Mandos server host.
>>
>> (Note; I have written these four steps mostly from my memory of how this
>> is supposed to work, but I have not tested them.  It is always possible
>> I have forgotten something.)
>>
>> /Teddy Hogeborn
>>
>>
>
> ______________________________**_________________
> Mandos-Dev mailing list
> Mandos-Dev at recompile.se
> https://mail.recompile.se/cgi-**bin/mailman/listinfo/mandos-**dev<https://mail.recompile.se/cgi-bin/mailman/listinfo/mandos-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.recompile.se/pipermail/mandos-dev/attachments/20130218/ce502ac6/attachment-0001.html>