2

Say you have a web server offering pages via HTTPS. After the process begins running, if you were to delete the private key, would this prevent private key recovery in case of server compromise? Assuming an attacker gains privileged access, wouldn't a memory scraper be able to recover the private key?

Is this design just a bad example of security through obscurity ?

8
  • 2
    Delete what private key? The on-disk private key file or something in-memory? Commented Dec 20, 2015 at 21:08
  • 6
    What would you do if you need to restart the webserver? Order a new certificate??
    – Philipp
    Commented Dec 20, 2015 at 21:38
  • Why delete it? Why not securely store it in another location?
    – schroeder
    Commented Dec 20, 2015 at 22:18
  • The private key for the SSL certificate. Imagine this scenario where the web server does not require a restart, ever. Assume the cert/key are already stored in a secure location but you wanted to add an additional layer of security in-case the server is compromised. Commented Dec 20, 2015 at 22:43
  • 4
    "Imagine this scenario where the web server does not require a restart, ever." I've tried hard to come up with such a scenario, but failed. What if you need to patch the server because of a vulnerability? If you assume that your web server is an impossibly perfect piece of software proven to have no vulnerabilities, then why do you assume that any other component in your architecture could be less perfect and allow to steal the key from the filesystem?
    – Philipp
    Commented Dec 21, 2015 at 1:55

2 Answers 2

3

Not worth it.

I understand that question to mean: "If I store the private key in RAM only, does this help security?"

Maybe. But this spells deployment hell.

I imagine this situation is similar to a server where you have to be physically present for reboot. Like with a boot-password. This is very unpractical. What you gain from this model is resistance against offline attack. Like if someone walks away with the server. You may actually want to defend against this if you don't really trust the server's physical security. But the more traditional way of defending against offline attacks would be full-disk-encryption.

If you want an unextractable private key, then you should look at buying an HSM. (The cheapest one I know is the $500 YubiHSM.) Or store the Keys off-server somehow, maybe in the way CloudFlare Keyless SSL works.

The advantage of these solutions is that Online attacks also no longer work. You can not extract the private key from RAM anymore, either. (And AFAIK private keys are one of the easier needles to find in the RAM haystack if you already have root on the box. Link: ErrataSec, Link: HeartLeech, Link: SecSe.)

1

You're talking about two types of security:

  1. Confidentiality of the SSL connection which depends on the private key being available and
  2. System integrity, which gets compromised before a private key becomes vulnerable.

The SSL connection that is established between clients and web servers depend on the private key being available so that it can complete the session key exchange.

If an attacker gains access to your system and gains elevated privileges, sure the private key on the filesystem is low hanging fruit, but a super user can also MMAP_PHYS in all system memory and scan it for the keys with just a little bit more trouble.

So, no, deleting the private keys would not prevent private key recovery (from memory), except if there's a power outage, reboot or something like that. Basically system integrity MUST be assured to keep your system resources (keys) safe from intruders.

Is this design just a bad example of security through obscurity ?

No, not security through obscurity. SSL is based on sound cryptographic concepts. Security in depth mandates that the private keys (read: system integrity) are protected by other layers of security such as mandatory access controls.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .