-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wed, Jun 22, 2005 at 01:20:10PM +0100, Colin McKinnon wrote:
On Wednesday 22 June 2005 13:12, Vasil Dimov wrote:
On Tue, Jun 21, 2005 at 10:29:37PM -0700, Peter Pentes wrote:
Sorry, what I am referring to here is actually the passphrase for the private keys, and how Stunnel does not support encrypted private keys.
This would be useless. How do you expect the passphrase for the encrypted private key to be obtained at stunnel startup?
Apache manages it.
Encrypted private keys will prevent stunnel from automatic startup, after a power failure or some other accidential machine reboot.
And even being crypted on the filesystem once decrypted the private key will stay in memory unencrypted all the time. If someone breaks in the machine while it is running he/she will get the key from memory not from the filesystem.
The only use of crypted private keys (for deamon-services) I can think of is that you can prevent someone from stealing your private key if he/she steals physically the harddisk or the whole machine from your server-room. And even this has the major disadvantage that the service will not start without human intervention (the private key's passphrase input) after unexpected reboots.
On Wednesday 22 June 2005 13:38, Vasil Dimov wrote:
On Wed, Jun 22, 2005 at 01:20:10PM +0100, Colin McKinnon wrote:
On Wednesday 22 June 2005 13:12, Vasil Dimov wrote:
On Tue, Jun 21, 2005 at 10:29:37PM -0700, Peter Pentes wrote:
Sorry, what I am referring to here is actually the passphrase for the private keys, and how Stunnel does not support encrypted private keys.
This would be useless. How do you expect the passphrase for the encrypted private key to be obtained at stunnel startup?
Apache manages it.
Encrypted private keys will prevent stunnel from automatic startup, after a power failure or some other accidential machine reboot.
Exactly. If it's simply a choice between having the facility or not, then by implementing it, it provides the systems owners with more choices. In some contexts it may be appropriate for an operator to control the boot-up process - denying access to network resources would be a good way of enforcing this.
....and it also presents the opportunity of supplying the certificate at runtime via a non-secure network protocol such as TFTP or NFS, and reduces issues with security of backups.
But yes, storing the passphrase on the same system makes no sense.
C.
-
Colin McKinnon -
Vasil Dimov