A related question: what's the best practice to encrypt the FS of a server and allow unattended reboots? One doesn't want to have to type in a password at each reboot (no unattended reboots and impractical for large number of servers) but the password can't be left attached to the server. So how is it done, if it is done? Thanks.
Mandos[0] does this, and allows you to configure a policy for how long the server is allowed to be offline without requiring an administrator to authorize boot. You could also cook up something for debian/ubuntu's support for embedding dropbear in the initramfs to supply a key.
1. The web page is not the primary entry point for the program; the Debian package is. So I don’t think the “bounce rate” is that large of a problem.
2. CAcert was chosen when the system was used for different purposes, in a different environment, by a different audience, and at a time when Debian shipped browsers with CACert’s root cert included. After that, it’s just been inertia.
3. I quote from the StartSSL F.A.Q.¹: “The Terms and Conditions of StartCom and the StartCom Certification Policy requires subscribers to provide the correct and complete personal details during registration.”. I generally don’t create accounts with external services, and as a sysadmin, I can and do run everything myself.
The only way to do this is to have the server only operate on encrypted data to begin with. Any scheme where the server can read the unencrypted data by itself can be subverted.
As with DRM, it is impractical to store both a lock and its key in the same place and expect it to be secure.
Exactly, that's why the password shouldn't be on the server, but having to type it in every time is inconvenient. Nothing I've been able to think about is secure so I was asking.
I also understand that any attacker gaining access to the server while it's running (the usual scenario) gets access to the unencrypted file system so maybe it doesn't make much sense to encrypt servers. Still I'm curious.
> Exactly, that's why the password shouldn't be on the server, but having to type it in every time is inconvenient. Nothing I've been able to think about is secure
That’s what I said to a friend of mine when we had numerous servers with encrypted disks and frequent power outages requiring us to type in passwords. He then suggested many different schemes to fix this, each of which I shot down as being insecure. Then he came up with something which I couldn’t shoot down, and he made a first proof-of-concept implementation, which is how Mandos¹ got started. This was many years ago; Mandos has since become available in Debian and Ubuntu; just do "apt-get install mandos".
