23

I want to generate a Certificate Signing Request for my server and in order to do so, I first need a secure private key. When I create a private key by using openssl genrsa -des3 -out server.key 2048, I'm asked to provide a passphrase. After doing some research, I found out that not having passphrase is a high security risk because once my private key gets compromised, the hacker will be able to decrypt everything that was encrypted using my key.

My question is: how is my server supposed to work with a private key that needs a passphrase. Since it is headless, there is no way I can enter the key when my server boots. How is Apache going to handle that?

I'm not asking how to remove the passphrase (I know how), I'm rather interested in how will my server be able to handle it and is it really a big security risk not to use a passphrase? I mean once the web server gets compromised, wouldn't it be easier to install a trojan horse?

Question Overflow
  • 5,220
  • 6
  • 27
  • 48
Matt3o12
  • 511
  • 2
  • 4
  • 10

3 Answers3

17

If you protect your private key with a passphrase, then Apache is unable to use it unless you supply Apache with the passphrase each time it restarts or you reboot. And since keeping that passphrase stored in the filesystem would defeat the point of the passphrase, that means having some sort of method to pass the passphrase to Apache from externally, each time it restarts or you reboot.

Some people do this, but its impracticality means most people use a non-encrypted private key.

If your private key is not encrypted, then its protection comes from the fact that only your superuser can read it, and therefore relies heavily on the integrity of the system and how susceptible it is to privilege escalation or the like.

If your private key is compromised then you can go to the signing certificate authority and ask them to revoke the certificate. Revocation is not a magic bullet however with some systems not checking for revocation and a typical delay between revoking a certificate and the information about the revocation being checked.

once my private key gets compromised, they hacker will be able to decrypt everything that was encrypted using my key.

This scenario is the kind of thing forward secrecy is designed to prevent. In TLS the two communicating parties can, if they both have the necessary support, negotiate settings which enable forward secrecy, so that in the event the private key is compromised it's still impossible to decrypt past communications.

The SSL Server Test can check to see if Forward Secrecy, among other things, is working on your server.

thomasrutter
  • 1,465
  • 11
  • 16
  • Incidentally, _Forward Secrecy_ usually wasn't enabled on SSL servers a couple years back because of the misguided belief that because perfect forward secrecy would either starve `/dev/random` or be exploitable for `/dev/urandom`. In practice, if your attacker can extrapolate the seed or SNR in your unblocking random source, then they are a government agency that can suborn your system with a FISA gag order anyway. – LateralFractal Oct 13 '14 at 06:24
1

I mean once the web server gets compromised, wouldn't it be easier to install a trojan hourse?

Essentially correct. Once an attacker has sufficient control over your server, they can usually just swap out your encrypted certificate for a cheap or free SSL certificate of the type that only confirms that you have access to the server (which the hacker does). Browsers as rule do not discriminate between certificates signed by any valid CA.

Or they can simply gut your Apache configuration to act as a reverse proxy to forward traffic to any address they choose.

The main benefit of a server with an encrypted SSL certificate loaded at runtime is that the certificate can't be stolen to perform a man in the middle attack. This is mostly relevant for systems where the attacker had only had limited control over the server; sufficient to steal data but not override assets and restart services.

LateralFractal
  • 5,143
  • 18
  • 41
1

I'm not asking how to remove the passphrase (I know how), I'm rather interested in how will my server be able to handle it and is it really a big security risk not to use a passphrase? I mean once the web server gets compromised, wouldn't it be easier to install a trojan horse?

To give a slightly different perspective on this. Asking the question as to whether something is a big security risk a little tricky. First off, lets ask this question, is the information stored on the website confidential? Is there more of a security risk if the site is offline? If you have confidential information on the website or travelling through the web site then it would be a high risk not to encrypt your private key. However if you do not have confidential information and it is more important that the site is up all the time then it may be more of a security risk to sign the private key, as the previous poster mentioned this will mean you have to enter the password on Apache load.

There are 3 areas of security, in general, Confidentiality, Integrity and Access, you would sign the cert if C&I are a concern and not if A is a concern.

Of course you can always have your cake and eat it to by having a Webserver farm, or even just vm instances, then load balance them with a health check on 443, this way traffic is redirected to Apache servers running while someone attends to entering the password for the private key, this just takes money, the more you have the more you can do.

Brett Littrell
  • 355
  • 2
  • 10