This brings up a good point: "if the physical web server were stolen". We already require disk encryption for our laptops. We are moving toward that for everything, including servers. Having an encrypted disk means you can't easily reboot remotely (at least not without a remote KVM), but, still, more people should do it.
-- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author, "Best Practices for Managing Linux and UNIX Servers" http://www.puryear-it.com/pubs/linux-unix-best-practices Identity Management, LDAP, and Linux Integration Tim Fournet wrote: > -ray wrote: >> Very true. So what do you do after an attack? Hope the attacker wasn't >> very savvy? Most of them aren't, but still... Guess it depends on what >> you're trying to protect. As an exercise, I downloaded the pcat utility >> (http://www.porcupine.org/forensics/tct.html) and dumped the memory from >> one of my Apache processes. I saw the strings 'PRIVATE KEY' and >> '---BEGIN---' '---END---' in a few places but couldn't find the actual >> key. Armed with a hex editor, the Apache source code, and perhaps a >> debugger, I think a semi-competent attacker could get the key pretty >> easily. >> > > One case where my usb-mounted drive or external mount suggestion would > help would be if the physical web server were stolen. If the drive is > gone, there's no key to steal, after the server's lost power. > >> I'll also argue that even if I gave you the private key in clear text, >> it's still a non-trivial task to capture the entire SSL session, replay >> and decrypt the data you want. Still very possible, but non-trivial. >> >> As a good security practitioner, it's always better to assume the worst >> than hope for the best. :) >> > But do you also just give up on any attempt at security just because > there's a case where it may fail? You're right that as long as the > machine has knowledge of the key, it can somehow get stolen, but if you > minimize the avenues that it can get stolen by, you have at least > minimized the risk by some degree. > > After the attack, what do you do? Revoke the certificate at the CA and > get a new one. > > > _______________________________________________ > General mailing list > General at brlug.net > http://mail.brlug.net/mailman/listinfo/general_brlug.net
