[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: public key crypto [was: Changing IP and Hostname...]

From: Brendan Strejcek
Subject: Re: public key crypto [was: Changing IP and Hostname...]
Date: Wed, 28 Apr 2004 11:46:58 -0500
User-agent: Mutt/1.3.28i

Christian Pearce wrote:

> I understand that. But if someone sits between you and the host
> couldn't they do something to the public key and create a man in the
> middle attack. You trust the wire to do the right thing. If I do it
> myself then I can trust it more.

That is correct. The problem exists for ssh also (in fact, any public
key distribution system). That is why some people put their gpg public
key fingerprint on their business cards (of course, then you need to
authenticate the business card, which was presumably done by face to
face contact with the card's owner).

It comes down to this: if you control both ends of the communication
channel (as is the case for most of us with cfengine) there is really
no reason to not manage the keys without resorting to network trust.
In the case of cfengine, the most important thing is to ensure the
master's public key is correct on the client, because that is what is
authenticating the policy being distributed by the master.

If you do not ensure that the master key is correct on all of your
clients, and you use TrustKeys in your initial client policy, there is a
window of opportunity during which an enemy could impersonate the master
and gain control of the client. This is effectively a root-level remote
(though practically, only local area network) exploit.

Ensuring that the master has the correct client public keys is less
important, because the function of that key is to act as access control
for who is permitted to download your policy files. Thus it is only a
confidentiality/information disclosure hole. Again though, since you
control both ends of the channel, why not manage it?

Summary: include your master cfengine key in your base OS installation
routine. That solves the problem.

Incidently, for ssh communication between machines on my network, I do
not trust the network either. I manage /etc/ssh/ssh_known_hosts with
cfengine. You could make this file public and sign it, if third parties
need to authenticate your ssh servers.

-- Brendan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]