5

Suppose I have a public/private keypair, which I would like to use to serve HTTPS from a webserver. The part I'm worried about is this: the private key is encrypted with a passphrase, so that if an attacker gains access to my webserver he doesn't get the private key. But I want some automated system to launch the webserver: say, monit to restart the server if it crashes, or puppet to deploy it to many different machines. Is this possible? It seems to me that I have three choices:

  1. Decrypt the private key and store it in plain text somewhere on the machine, in an area that I hope an attacker will be unable to compromise.
  2. Store and use the encrypted key, but also store the passphrase for use by automated systems. This doesn't seem fundamentally any more secure than (1).
  3. Store only the encrypted key, and require manual intervention anytime a server needs to be started.

Are there any options I'm missing? I can't imagine large-scale websites like Wikipedia or Google require manual intervention to start a server, so I'm guessing they must be storing the cleartext keys; but that seems like it must be a bad security practice.

amalloy
  • 153
  • 8

2 Answers2

3

A server restart is a serious occurrence, and should never happen on its own. Ideally there should be an admin logged on to trigger the restart - or at least to restart the server after he/she has diagnosed why it went down in the first place, if it was an unscheduled down.

So the admin may supply the passphrase manually.

As a weaker alternative, the SSLPassPhraseDialog may be used to supply the passphrase.

To strenghten the scenario, the script itself has to be secured (otherwise it's no better than a cleartext passphrase, or no passphrase), so it would have to ask for the passphrase to a second server that has some means to ascertain whether the request is legitimate or not.

For example, if there is a diagnosed down on the server, then and only then a SSH login for the servermaint user from that one IP is granted and the correct password echoed:

ssh -i identity_file servermaint@passphraseserver "getpassphrase"

And the identity_file only identifies that one server with a known IP address.

An attacker gaining access to the Web server would find no passphrase, and would be unable to login to passphraseserver (actually he would, but such an attempt would trigger an alert and log him instantly off instead of supplying the passphrase - and would also mark the server as compromised).

An attacker would then have not only to break into the server, but also to cause a webserver shutdown, and remain in control of the webserver while shutdown diagnostics and forensics are carried out - an unlikely event at best: with that kind of control, he might be able to exploit the Apache process and get a copy of the passphrase when the real sysadmin types it in.

Of course, in a simpler and way more common scenario ("I just want my server to go back up if it goes down, as fast as possible - don't care why it went down, it will always happen every now and then"), it would be easier to leave out the passphrase altogether.

LSerni
  • 22,521
  • 4
  • 51
  • 60
  • "A server restart is a serious occurrence, and should never happen on its own." -- Shouldn't, but it does. You could spend a lot to try to make something bulletproof (and it still won't be) or spend a little to make it fault tolerant. – u2702 Jul 12 '13 at 21:35
  • Yes, of course. In truth, you factor the cost of any given decision. It all depends on the particular system: you might want some systems to be *totally not fault tolerant*, and *go down and stay down* rather than trying to operate in unsafe conditions. On my own web site I wouldn't even *have* a passphrase. On my bank's, though, I'd not be satisfied by my own 'scripted passphrase' suggestion. – LSerni Jul 12 '13 at 21:46
  • Agree. How far you go to protect the cert should depend on what that cert protects. – u2702 Jul 12 '13 at 21:53
  • Disagree with "shouldn't". No one operates that way, anywhere, except perhaps in classified environments. If that is your security requirement, you probably should not be connected to the Internet (aka air gap installation)! – Charlie Reitzel Jul 08 '22 at 16:40
3

You're assessment that 2 isn't any more secure that 1 is correct. It's another step for an attacker to untangle but not that challenging.

Option 3 is better than 1 and 2 but a smart attacker with root-level privileges can probably pry your certificate out of memory.

Bottom line: your server needs to have your certificate in unencrypted form to serve HTTPS traffic and someone with root-level access is going to be able to get to it. It's just a matter of time and effort.

Your best option is to protect your certificate on the host with file permissions, run your server with sub-root privs (having it drop from root to nobody or http after it's bound to port 80 and 443 and loaded the cert) and monitor the host for unusual behavior.

If the worst should happen and your cert is compromised, that's what certificate revocation lists are for.

[Edit] One additional thing... the protections you put around your cert should depend on the level of risk you're willing to accept.

u2702
  • 2,086
  • 10
  • 11
  • +1 for the host monitoring tip, as well as the vulnerability of memory: http://www.hsc.fr/ressources/breves/passe-partout.html.en – LSerni Jul 12 '13 at 22:24
  • Some machines also have a [TPM](http://en.wikipedia.org/wiki/Trusted_Platform_Module), which would allow a more secure use of a certificate, but this appears unsupported as yet by web servers (or at least apache and nginx). – user2313067 Jul 13 '13 at 21:46
  • Routing every SSL session setup through a TPM probably isn't going to scale. – u2702 Jul 16 '13 at 16:26