Yedidyah Bar-David wrote:
You have to realize this is an inherent problem, not something technical you can work around. If you want encryption, you have to supply a key. If you do not want to do that yourself at boot, you have to put it in the server somehow. Some ways to put it in the server are more secure than others, but if anyone has physical access to it he got your key.
I'm aware of this, that's where my question came from.
That said, while I never worked with one, I have a feeling a smartcard implementation has the potential to be much more secure than a file on
That's the sort of solution I was wondering about.
the disk, and still managable. You can also think about software-onlyWell - with such access to the host you can also probably sniff the key from Apache's
solutions that will be good enough for most people. E.g. you can put
the key on comodity hardware (Disk-on-Key?) that's inaccessible after
bootup (because you rmmoded its driver and prevented further insmoding.
Note that IIRC there is already proof-of-concept code that changes a
running kernel even with modules disabled, though).
memory can't you?
How about an external (USB? Firewire?) box which doesn't reveal the key but can be
used by Apache to decrypt/encrypt the SSL stream? Do such things exist?
I take it from the answers so far that organizations just ignore the problem and leave their
private keys as-is on their host and hope it doesn't get stolen.
Maybe a mitigating action would be to sign a "temporary server key" with the real key
they got from Verisign and keep the real key on a CD in a safe, so if the temporary key
gets stolen they can sign a revokation for it and create a new one?
Cheers,
--Amos
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
