[Help-gnutls] Re: Announcement: Yet another GnuTLS-using program: Mandos

[Teddy Hogeborn]

Simon Josefsson <simon at josefsson.org> writes:

> Cool!

Thank you!

>> The Mandos client connects to the Mandos server.  The Mandos
>> clients each have an OpenPGP key, which they use to handshake as
>> TLS *servers* to the Mandos server, which in turn handshakes as a
>> TLS *client*.  The Mandos server does not have a key, but computes
>> the fingerprint of the OpenPGP key received from the Mandos client
>> and looks up that fingerprint in an internal list, and, if the
>> fingerprint is found, sends the corresponding binary blob to the
>> client.
[...]
> I'm not sure you have to do the handshake backwards, couldn't just
> the mandos server have a OpenPGP key that the mandos client doesn't
> need to validate?

Yeah, but why?  First we'd have to generate a key on the server on
installation, which would take a lot of time and entropy for no
reason.  And then we'd have an extra file to read (extra code) and
manage (more code at installation and uninstallation to make sure the
file is there and preserved, etc.).  We'd also have to make sure the
server requires an OpenPGP certificate from the clients, which would
mean even more code.  But, doing the handshake the other way around
gets us exactly what we want, for free.

Is there a good reason to go though all that trouble to do it the
"normal" way?

> One additional idea I get is to add some mechanism in the Mandos
> server to require authorization before sending the blob.  I.e., the
> administrator is sent a jabber/e-mail/whatever ping that some
> machine needs to reboot, and then she needs to go to a web page and
> authorize the operation.  Otherwise, the machine cannot boot.

That would indeed be a useful feature.  One of the features we are
most likely to implement next (already in our TODO file) is the means
to communicate (locally) with the server and list/edit current
enabled/disabled clients (see below).  This interface could then be
used by some web-accessible program, like you suggest.

> This might introduce network timeouts, but if the Mandos client is
> robust about that there shouldn't be a problem.

I'm not sure what you mean.  Should not a TLS connection over TCP be
alive indefinitely even if no data is sent over it?

> This would protect against someone stealing a server without keeping
> it powered.

What I did not mention in the announcement (because it was not
directly related to GnuTLS) is that the Mandos server periodically
checks the online status of all the clients, and if a client has been
down for too long, it no longer gives out the encrypted key.  The
timings and checking method can be individually configured.

> You'll have a problem if someone also gets control of the Mandos
> server though...

If you by "control" mean "physical access", then no, not if the Mandos
server also has an encrypted file system.  But if you by "control"
mean "root", then yes, if someone gets root on the Mandos server and
*also* physical access to the Mandos clients, the game is lost.  Root
access has always been bad news.

The point is, any one of those things only gives half of the key; an
attacker would need both physical control of a Mandos client *and*
root on the Mandos server to successfully decrypt the clients' disks.

> Maybe one could extend the scheme, so that N out of M machines have
> to participate in reconstructing the blob before any single machine
> can boots.  Just getting control of <N of the M machine should not
> reveal any information.

I don't really see how this could be useful, since the client machine
must be able to construct a file system key using only its OpenPGP key
and a network connection.  Therefore, regardless what hoops you make
it jump through, anyone with access to that key could perform the same
action it does and get the file system key.

Wait a minute, you mean to protect against someone getting root access
on the Mandos server?  Then you are correct, it would lower the
information exposure if that were to happen.  Oh well, that can wait
until version 2.  :-)

Protecting against someone with root access has never been our
priority; our primary goal has always been to protect against physical
removal of the servers.  Not saving the encryption keys in the clear
on the server was just a sudden attack of common sense, not really
meant as a real defense against someone with root on the Mandos
server.

> Whether this aspect is useful depends on your threat model.  Maybe
> your model is different from what I assumed...

I would direct your attention to the FAQ and Security Summary, both of
which are contained within the README file:

http://bzr.fukt.bsnet.se/loggerhead/mandos/trunk/annotate/head:/README

>> Oh yes, the project's home page:  http://www.fukt.bsnet.se/mandos
>
> Thanks, added to <http://www.gnu.org/software/gnutls/programs.html>.

Thank you!

/Teddy Hogeborn & Björn Påhlsson, the Mandos Team
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: </pipermail/attachments/20081008/33480858/attachment.pgp>