On Wed, 2003-12-31 at 15:13, Todd Freeman wrote:[...]

Nice work, but is it really necessary? All you need to do to avoid the
password question is to have no password - as described on the Pound
page, in the README and the FAQ. Have a look at the -nodes option for
openssl.

I know some people object to having the private key without a password
for it - but having the password (in clear !) in a disk file is not
really a security improvement...[...]

Umm... well the certs that we use are Verisign certs and they REALLY
frown on certs with no passphrases.

We have to use the base certs (not extrusions or derives) because of
some intricacies in the way that Oracles OAS web services require SSL.

Also... If properly set up (needs a bit more modification) the
passphrase is read before a chroot to the jail. Hence... it is read from
a file that ceases to exist. If that is on an encrypted drive that is
unmounted after startup then voila... about as safe as you can get.

I would love to be passphrase free... but unfortunately that can't
happen. Plus... if you have no passphrase your key is SIGNIFICANTLY
(read trivial) easier to coopt if someone gets in.


On Mon, Jan 05, 2004 at 01:53:59PM +0100, Robert Segall wrote:[...]
[...]

On Mon, 2004-01-05 at 14:32, Todd Freeman wrote:[...]

I think that it's YOUR certificate, and as such you may use it in any
form you care - inclusive of password-less. Verisign has no saying in
it.
[...]

Removing the password is not a derivation - the original certificate is
not changed in any way, and I never heard of an application that refuses
to use a certificate without a password.
[...]

Same is true of the certificate without a password - it is not
accessible from the root jail. If you put them on an encrypted drive you
have exactly the same password-on-boot problem, only now it is for
mounting the drive rather than accessing the key.
[...]

Again - with the password available in a file it is an identical
situation. What is the SIGNIFICANT difference here?

All in all I fail to see how a password-less certificate is less secure
than having the password in a file. Would you care to describe a
scenario that allows an intruder to do anything more with it than by
having the password?[...]

On Mon, Jan 05, 2004 at 03:10:05PM +0100, Robert Segall wrote:[...]

Agreed...
[...]

Try oracle's (albiet older) OAS web server... it is 100% umm... anal
retentive.
[...]

Nope... the encrypted drive is mounted based on a physical security
device locked in our machine room. No passphrases involved anywhere.
[...]

The passphrase is in a file that #1 doesn't exist after the jail... and
#2 even if they get into the machine the chances of them successfully
mounting the secure partition to get the passphrase is zilch. That is way
more secure.
[...]

Without any passphrase... anyone that gets your secret file can masquerade
as you... with a passphrase they can't do that. Simple as that.... it is
one more layer of protection.

And just because you're paranoid doesn't mean they arn't out to get you.
[...]
[...]

On Mon, 2004-01-05 at 15:24, Todd Freeman wrote:[...]

So you replace a password with a magical security device - which is
either accessible at all times (to allow for unattended reboots) and
thus the exact equivalent of the "password in the file", or it isn't -
which requires manual intervention on booting...
[...]

This is too magical for me: you mean if I get root on your machine I
can't mount the partition, but that it can somehow be mounted at boot
time without operator intervention?
[...]

Not if the password is available in clear: that allows me to do exactly
the same operations as a key without a password - thus no extra
protection.
[...]

Very true, and (sadly) often ignored...[...]

On Mon, Jan 05, 2004 at 05:23:56PM +0100, Robert Segall wrote:[...]

Not magical... The security key is only available during the boot
process. After that it is disabled from an init script. Root CAN NOT use
that security device again until the system has been rebooted (the
device knows about resets).

Hence my reasoning... it is secure once boot up has taken place... and
we provide no network access (beyond pound) until the security card has
been disabled. No ssh... telnet... nothing...
[...]

Exactly... Nothing magical in truth... but any sufficiently advanced
technology is indistinguishable from magic :P
[...]

It isn't so... :P
[...]
[...]

On Mon, 2004-01-05 at 17:35, Todd Freeman wrote:[...]

Sounds like a really neat device - could you tell us more about it? I'm
sure quite a few people could use something like this - we (Apsis)
certainly would...
[...]

Any reason why your unencrypted certificate could not be on your device
instead of the password?

However I think we are getting a bit side-tracked here: my main claim is
that a certificate+password combination is the exact equivalent of the
unencrypted certificate: they can be used in exactly the same way and
for the same purposes. It matters not what security mechanism you apply
to protect the password - the same mechanism can be applied to the
certificate.

My conclusion is that you do not need the extra layer of complexity for
the password. If you think different please show a scenario where an
attacker could benefit from an unencrypted certificate but not from the
password (when both are protected in the same way).[...]

This is starting to sound like the meta record and player from GEB.
It really boils down to "Is the effort of implementation worth the increased
security?".  I think most people here would say no.
	
	In general the secret side of keys are lying around all over our
servers one way or another.  Some precautions are well warranted, but in
general a lot of them for servers are over the top.  So long as the keys are
in the active memory of a process on the server then I don't think hiding
them from root is really of much use at all (I can think of three attacks as
root quite easily).  That is why people with that security concern use an
external encryptor/decryptor.  You just place requests to it over a local
bus (SCSI, PCI, serial, maybe even USB by now).  The key is stored in the
hardware and can only be accessed out of band via another port.  These boxes
demand a large price tag (last time I looked they tended to start at $10K
and go up rapidly), but well worth it if the security of root is not enough
for you.

	Until rootless systems become common I think the issue of encrypted
secret keys for server processes is moot.

	73,
		Shawn

[...]