Tracy R Reed wrote: > > I do not know of any production shop that DOES store the HTTPS key > encrypted on disk.
University of California, Academic Computing Services. Now you know one. > The first time the site is down because you weren't there to unlock > the key or the box rebooted somehow and the site didn't come up > automatically you quickly realize it isn't worth it. Better to just > keep the box secure. Nice, in theory. Those pesky 0-day volnerabilites, along with the path leackages make this a poor idea. However, a lot of sites do exactly that because of the tradeoff between security and convenience. > How about some practical suggestions which you have actually > implemented on how to accomplish these things? Practical suggestions > will be littered with the phrase "good enough". https: An email goes out to the admin group stating that the https dd not start, and needs to be started manually. That works. good enough. At least for ACS at UCSD. In your MySQL application, liberal use of AES_ENCRYPT and EAS_DECRYPT would do wonders for protecting sensitive data. Users of FreeBSD have enjoyed, for years, enjoyed the benafts of an encrypted swap (while swap does not get backup up to tape, it does exst on the spining disks that go missing[1]) [1] Where go missing can mean sold on e-bay. PostgreSQL offers mechanisms for encrypting fields of a table. Are these practical, and good enough for you? Or do you need more? If you need ideas for a specific example, I would be happy to brainstorm with you. If you are just trying to play Stump the Chump, find another chump. -john -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
