Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Webservers shouldn't have direct access to keys

plus.google.com

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Webservers shouldn't have direct access to keys

#31

Post by remosi »

pedrocr wrote: post #4

This seems like a good idea but this fixation on PKCS#11 seems strange. Why use a whole API when Apache and Nginx can just add a simple daemon with their own internal API to do this? The same amount of security can probably be obtained by just launching a process on server startup to do this with sufficient isolation from the parent process. I believe OpenSSH does something along these lines to run most of its code a…

The major reason is that when your website becomes popular, and becomes more of a target, you can swap out the software hsm daemon with a more sophisticated hardware solution, if implemented properly, by just changing a pkcs11: url[1] to point at the new HSM.

PKCS#11 has a few irritants, but it's a fairly sensible API. and it's already implemented by many things (browsers, gnome-keyring, ssh, ...). OpenSSL, GnuTLS at least both support it via one mechanism or another, my only real complaint from the webserver side is that the configuration knobs aren't really plumbed through.

[1]: http://tools.ietf.org/html/draft-pechanec-pkcs11uri

Re: Webservers shouldn't have direct access to keys

#32

Post by __david__ »

bcoates wrote: post #15

Wouldn't it make sense to lower the exposure by having the server only have access to its own ephemeral private key? So instead of having the key to the hard to change site certificate on many vulnerable front-line servers, it rolls up a key and on boot sends a certificate signing request to a hardened internal system?

It would have to be time based, not boot based, unless you want to do key revocation for all the previous at-boot-time generated keys. But yeah, if you rotated keys once an hour or once a day, then if they got leaked the window for MITMing your customers would only be that long.

Re: Webservers shouldn't have direct access to keys

#33

Post by stcredzero »

callesgg wrote: post #28

The stuff that should encrypt, should have the keys. That is how easy it is. Personally I think the web server should do the encryption. As it is the part of the software that contains the sensitive information, AKA the content. You can get new keys you can't get new content.

I appreciate your contrarian position, but I don't think you've thought this out. The problem with "just getting new keys" is that there is no guarantee of detection of a key breach. So you might desperately need to get new keys, but not know it for months. Meanwhile, bad people have access to that all-important content.

Protecting content involves protecting keys. So to prioritize protecting content, you have to prioritize protecting keys.

Re: Webservers shouldn't have direct access to keys

#34

Post by remosi »

hibikir wrote: post #14

Key management is a major issue across the board, not just web servers. Even a theoretically unbreakable crypto will always have a weakness if the keys themselves are compromised. Stopping keys from being copied is a major challenge though, because anything you can do to truly protect them involves major hassle. Think of the problems credit card processors deal with: Hiding the keys themselves from their own employee…

If I was running a bank, I'd hopefully use a proper HSM. You ask it to generate a private key, you then ask it for the public key, get it signed into a cert, and use that. The HSM promises to never give out the private key to anyone (including the administrator), usually in a tamper evident way (if someone did manage to extract the key, you'd notice). Even if you have root on a machine that has an HSM plugged into it, you can't get the private keys out.

However, my personal webserver isn't a bank. Not everyone can justify spending this much money on a HSM to get this level of assurance. What I'm proposing is a simpler solution that isn't robust against sophisticated attacks (eg when the attacker manages to get root), but is far more robust to some classes of the common attacks we see today (where the attacker can read any memory/file that the webserver has permissions to see).

Re: Webservers shouldn't have direct access to keys

#35

Post by joosters »

Is everyone falling into the trap of over-securing last week's security problem? Isn't this just like banning water bottles on planes after a failed liquid bomb attack?

Be careful that in our haste to secure the private keys, we ignore easier attacks. The article seems to gloss over an attacker hacking the web server, when in fact that gives them such powers that going on to grab the private key might not even be attempted.

Re: Webservers shouldn't have direct access to keys

#36

Post by pedrocr »

remosi wrote: post #31
pedrocr wrote: post #4

This seems like a good idea but this fixation on PKCS#11 seems strange. Why use a whole API when Apache and Nginx can just add a simple daemon with their own internal API to do this? The same amount of security can probably be obtained by just launching a process on server startup to do this with sufficient isolation from the parent process. I believe OpenSSH does something along these lines to run most of its code a…

The major reason is that when your website becomes popular, and becomes more of a target, you can swap out the software hsm daemon with a more sophisticated hardware solution, if implemented properly, by just changing a pkcs11: url[1] to point at the new HSM. PKCS#11 has a few irritants, but it's a fairly sensible API. and it's already implemented by many things (browsers, gnome-keyring, ssh, ...). OpenSSL, GnuTLS at…

That would be an argument for supporting both. I fear that otherwise what you will end up with is that a minority of security conscious people will have HSM (actual hardware or software) and most others will just configure their Apache/nginx software as quickly as possible and get on with it. Having the basic config be more secure by spawning the soft-hsm itself sounds like a win.

Re: Webservers shouldn't have direct access to keys

#37

Post by nly »

remosi wrote: post #26
nly wrote: post #7

This really isn't really the end of the story. As far as your web app goes, HTTP cookies can be just as or more sensitive than your SSL keys, and they also slop around in your web servers memory. This is one reason why we run SSL/TLS in the first place, after all. In many cases we really use TLS as a way to ensure application layer authentication. Confidentiality, in and of itself, is often not the primary concern. D…

You're right, this doesn't solve 100% of the problem. If I could solve 100% I'd be creating a startup... Cookies are remarkably sensitive, but they can be far more easily rotated. I can make sure that every cookie is rotated transparently every day or so and leave that running as a sensible background precaution. If we had infrastructure that let us renew our TLS keys every 24 hours or so, this wouldn't be such a big…

> If we had infrastructure that let us renew our TLS keys every 24 hours or so

The sad thing is... we do. 24 hours is a bit much, but why not have a different certificate for each server? The whole point of a certificate chain is to give us the flexibility to issue and revoke certificates from lower down in the tree... of course most of us serfs don't get the privilege of using our own intermediates.

Oh... and we're repeating some of the same mistakes in DNSSEC. Looking at deploying DNSSEC I kept reading that the general idea of the KSK was to function as a long-term key, and the ZSK as a short term key, but I have yet to see a method of managing things with the KSK offline that isn't like pulling teeth. The latest BIND requires that both the KSK and ZSK private keys be resident on your primary nameserver when you switch on the "auto-dnssec" magic.

Still, at least setting up DNSSEC is free.

Re: Webservers shouldn't have direct access to keys

#38

Post by mhb »

remosi wrote: post #34
hibikir wrote: post #14

Key management is a major issue across the board, not just web servers. Even a theoretically unbreakable crypto will always have a weakness if the keys themselves are compromised. Stopping keys from being copied is a major challenge though, because anything you can do to truly protect them involves major hassle. Think of the problems credit card processors deal with: Hiding the keys themselves from their own employee…

If I was running a bank, I'd hopefully use a proper HSM. You ask it to generate a private key, you then ask it for the public key, get it signed into a cert, and use that. The HSM promises to never give out the private key to anyone (including the administrator), usually in a tamper evident way (if someone did manage to extract the key, you'd notice). Even if you have root on a machine that has an HSM plugged into it…

For other curious readers:

HSM = Hardware Security Module (http://en.wikipedia.org/wiki/Hardware_security_module)

Re: Webservers shouldn't have direct access to keys

#39

Post by pedrocr »

remosi wrote: post #25
pedrocr wrote: post #19

Earlier quoted context omitted.

>PKCS#11 already exists, is already supported by software and hardware vendors It's apparently not supported by Apache/nginx nor does a suitable software-HSM exist to use it, so you're basically writing both ends of the communication. But if you do go with a separate daemon PKCS#11 may very well be a good solution. I just think forking off a process yourself is much cleaner for the use case of securing a web server.

There are several softhsm's, they just share the address space with your frontline daemon which (IMHO) defeats the purpose. While webserver's support for PKCS#11 is annoying, it's well supported by lots and lots of other stuff (usually client side stuff like ssh, browsers etc tho). You can get webservers to do PKCS#11 today, there are docs on how to do it. They usually start with "download the source, and run configu…

Isn't that just because PKCS#11 is an in-process API so not really meant for calls over a socket? So wouldn't you need to actually write a PKCS#11 compliant library to plug into the server, a software HSM and then some form of serializing protocol to talk between the two? Or is there a standard way to do PKCS#11 over a socket? A quick look at the spec made it look like a "here's how our struct's are packed" kind of standard.

Re: Webservers shouldn't have direct access to keys

#40

Post by remosi »

nly wrote: post #37
remosi wrote: post #26

Earlier quoted context omitted.

You're right, this doesn't solve 100% of the problem. If I could solve 100% I'd be creating a startup... Cookies are remarkably sensitive, but they can be far more easily rotated. I can make sure that every cookie is rotated transparently every day or so and leave that running as a sensible background precaution. If we had infrastructure that let us renew our TLS keys every 24 hours or so, this wouldn't be such a big…

> If we had infrastructure that let us renew our TLS keys every 24 hours or so The sad thing is... we do. 24 hours is a bit much, but why not have a different certificate for each server? The whole point of a certificate chain is to give us the flexibility to issue and revoke certificates from lower down in the tree... of course most of us serfs don't get the privilege of using our own intermediates. Oh... and we're…

The technique of not having the keys available to the process that's dealing in external bits works really well for DNSSEC. There's a program called opendnssec which takes care of keys, rotating them, and .... accesses them via PKCS#11. So you can use Hardware Security Module, or a softhsm. Since it's opendnssec that's doing the rotation of keys, that can run as a different user than your DNS server, so the fact that softhsm runs as a shared library is less of an issue.

opendnssec unfortunately is a little... industrial strength. It takes some time and consideration to configure unlike bind's "gimme the keys and I'll just take care of it for you" approach.

Post reply on HN