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

41–50 of 78 posts

Re: Webservers shouldn't have direct access to keys

#41

Post by remosi »

joosters wrote: post #35

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 att…

Yup. But when you have a successful attack you should consider what alternatives you have to make sure that never happens again. You might dismiss them since their cost:benefit might not be favourable. If this works, I doubt many people are going to deploy it by default, since the cost:benefit doesn't pay off for them. But it might pay off for some other people who are really pissed off right now.

Re: Webservers shouldn't have direct access to keys

#42

Post by derefr »

ctz wrote: post #30
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?

This is feasible in the current X509 public CA system, thanks to name and path length constraints. However, I don't know of any CAs which will issue restricted suitable certs for any sensible amount of money.

I'm very confused why the X.509 model isn't already set up to accommodate this. Imagine that a CA could only sign CSRs for subjects hierarchically-below its own subject. Then:

• Instead of issuing plain leaf-node certs, CAs could (and would) issue CA-certs by default.

• You'd be able to issue as many plain certs as you like, using your own CA-cert, and revoke them as often as you like. (OCSP would be much more necessary here.)

• The current CAs would be renamed to "global CAs": their power would come from the fact that they have no subject (or their subject is '.') in their CA-certs.

• Anyone owning a domain would become the CA for its own subdomains. (foo.tumblr.com would be signed by Tumblr's CA; foo.s3.amazonaws.com would be signed by the Amazon AWS CA; etc.)

Re: Webservers shouldn't have direct access to keys

#43

Post by teacup50 »

pedrocr wrote: post #19
teacup50 wrote: post #16

Earlier quoted context omitted.

The value, in theory, is that PKCS#11 already exists, is already supported by software and hardware vendors, and is already comprehensive enough and has seen sufficient review to cover the gamut of use cases that such a solution would need to support. PKCS#11 is a little funny looking and has some small rough edges, but it's actually reasonably designed and easy to implement from scratch. That's not something I can s…

>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.

> 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.

Apache/nginx don't have to support pkcs11, they just need to support the use of existing crypto libraries that already support pkcs11:

http://www.gnutls.org/manual/html_node/Using-a-PKCS11-token-...

If a server uses gnutls and passes the user-supplied filename directly to gnutls_certificate_set_x509_key_file2(), a PKCS#11 URL can be used directly without changes to the server.

> I just think forking off a process yourself is much cleaner for the use case of securing a web server.

It's something that everyone has to write for every server; people will get it wrong. Additionally, there's no support for hardware modules or plugging in new software security modules, so you'd be starting with a handicapped solution.

Re: Webservers shouldn't have direct access to keys

#44

Post by remosi »

pedrocr wrote: post #39
remosi wrote: post #25

Earlier quoted context omitted.

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 s…

Yup, that pretty much sums it up. I'm currently trying to figure out if dbus could be that serialisation since it takes care of a reasonable amount of the hard work for you. But I'm no expert on GObject, so slow going. (Also, I'm not sure that I'm the best person to be writing this... I don't really have that much security knowledge, I just spent a whole pile of time trying to figure out how to secure my (client) keys recently and wondered why we didn't do something sensible for server keys.

Re: Webservers shouldn't have direct access to keys

#45

Post by teacup50 »

joosters wrote: post #35

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 att…

OpenSSL isn't last week's security problem: The code didn't magically get better in a week, and all signs indicate that there are likely more serious issues in the library.

Looking past OpenSSL, C didn't magically become a safe language in a week, either; this approach guards against a real problem in C that is not limited to a single bug in OpenSSL: over-reading off the end of a valid buffer.

Re: Webservers shouldn't have direct access to keys

#46

Post by pedrocr »

remosi wrote: post #44
pedrocr wrote: post #39

Earlier quoted context omitted.

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 s…

Yup, that pretty much sums it up. I'm currently trying to figure out if dbus could be that serialisation since it takes care of a reasonable amount of the hard work for you. But I'm no expert on GObject, so slow going. (Also, I'm not sure that I'm the best person to be writing this... I don't really have that much security knowledge, I just spent a whole pile of time trying to figure out how to secure my (client) key…

In that case why not skip the middle man and just implement enough soft-HSM for whatever Apache/nginx needs with a simple serialization protocol just for that? Emulating all of PKCS#11 sounds like a chore for very little gain.

Re: Webservers shouldn't have direct access to keys

#47

Post by antocv »

derefr wrote: post #42
ctz wrote: post #30

Earlier quoted context omitted.

This is feasible in the current X509 public CA system, thanks to name and path length constraints. However, I don't know of any CAs which will issue restricted suitable certs for any sensible amount of money.

I'm very confused why the X.509 model isn't already set up to accommodate this. Imagine that a CA could only sign CSRs for subjects hierarchically-below its own subject. Then: • Instead of issuing plain leaf-node certs, CAs could (and would) issue CA-certs by default. • You'd be able to issue as many plain certs as you like, using your own CA-cert, and revoke them as often as you like. (OCSP would be much more necess…

Because your browser doesnt know the chain, yourdomain.com could sign google.com and browser will accept it as is today.

For your proposal to work the CA system would have to check with dnssec and probably another protocol to enforce the subca signs only its domain constraint.

Re: Webservers shouldn't have direct access to keys

#48

Post by pedrocr »

teacup50 wrote: post #43
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.

> 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. Apache/nginx don't have to support pkcs11, they just need to support the use of existing crypto libraries that already support pkcs11: http://www.gnutls.org/manual/html_node/Using-a-PKCS11-token-... If a server uses gnutls and passes the user-supplied filename d…

>Apache/nginx don't have to support pkcs11, they just need to support the use of existing crypto libraries that already support pkcs11

Fine you get Apache->SSLLib->PKCS#11. Now you need to write a PKCS#11 compliant library to talk to your HSM, and a custom serialization protocol for that communication anyway.

>It's something that everyone has to write for every server; people will get it wrong. Additionally, there's no support for hardware modules or plugging in new software security modules, so you'd be starting with a handicapped solution.

If we're worried about http servers it's basically apache/nginx. As I mentioned in another comment if apache/nginx implement this directly most users will get it by default. If they implement it with a separately configured daemon only very security conscious people will do it. So if your objective is preventing the most dangerous bugs in the most exposed daemons (and HTTPS tends to be that) in the most number of cases doing this directly by default in those two servers seems like a better solution. That doesn't stop you from also doing the other option to support actual HSMs and other fancy 1% cases.

Re: Webservers shouldn't have direct access to keys

#49

Post by jakobe »

Mac OS X has something similar to this "Software HSM": the Keychain. You can put private keys in your keychain, and apps can use them for signing or encrypting, but they can't extract them. It's quite nicely implemented; when an app tries to access a key the first time, a dialog will pop up saying something like "Mail is trying to use key xyz for decryption. Do you want to allow?".

Of course, this requires using Apple's APIs, which are poorly documented and a pain in the neck even compared to OpenSSL. It's also not suitable for servers.

Re: Webservers shouldn't have direct access to keys

#50

Post by teacup50 »

pedrocr wrote: post #48
teacup50 wrote: post #43

Earlier quoted context omitted.

> 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. Apache/nginx don't have to support pkcs11, they just need to support the use of existing crypto libraries that already support pkcs11: http://www.gnutls.org/manual/html_node/Using-a-PKCS11-token-... If a server uses gnutls and passes the user-supplied filename d…

>Apache/nginx don't have to support pkcs11, they just need to support the use of existing crypto libraries that already support pkcs11 Fine you get Apache->SSLLib->PKCS#11. Now you need to write a PKCS#11 compliant library to talk to your HSM, and a custom serialization protocol for that communication anyway. >It's something that everyone has to write for every server; people will get it wrong. Additionally, there's…

> Fine you get Apache->SSLLib->PKCS#11. Now you need to write a PKCS#11 compliant library to talk to your HSM, and a custom serialization protocol for that communication anyway.

HSM modules already have PKCS#11 drivers, because it's a standard, and that means they work readily with existing software and cover the requisite industry use-cases.

You're proposing taking web servers in a different direction simply because you find the general, widely supported solution to be antithetical to your tastes?

Unless you're actually going to write code here, I don't really understand why you care, or why you're advocating ignoring hard-won wisdom and experience that's encoded in a decent spec, just because you don't think you'll like it.

Post reply on HN