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

51–60 of 78 posts

Re: Webservers shouldn't have direct access to keys

#51

Post by DrStalker »

jakobe wrote: post #49

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

That wouldn't help when there is a bug that lets an attacker read your server's memory; you'd still need to reissue your certificates as a preventative measure because you couldn't guarantee that the bit of memory used by the software HSM hadn't been compromised.

Re: Webservers shouldn't have direct access to keys

#52

Post by teacup50 »

DrStalker wrote: post #51
jakobe wrote: post #49

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

That wouldn't help when there is a bug that lets an attacker read your server's memory; you'd still need to reissue your certificates as a preventative measure because you couldn't guarantee that the bit of memory used by the software HSM hadn't been compromised.

The keychain operates out-of-process.

Re: Webservers shouldn't have direct access to keys

#53

Post by pedrocr »

teacup50 wrote: post #50
pedrocr wrote: post #48

Earlier quoted context omitted.

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

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

The OP isn't talking about using an actual HSM, but using a new software based daemon to do the HSM role just so the crypto calculations (and the key) aren't in the webserver's address space. He confirms that he is indeed trying to write the PKCS#11 driver himself. Just using the existing crypto code in Apache/nginx but moving it into a separate process seems much cleaner to me and has the one feature this suggestion doesn't, it works with existing config files without modification so will be used much more widely. That's all I am saying.

Re: Webservers shouldn't have direct access to keys

#54

Post by teacup50 »

pedrocr wrote: post #53
teacup50 wrote: post #50

Earlier quoted context omitted.

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

>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. The OP isn't talking about using an actual HSM, but using a new software based daemon to do the HSM role just so the crypto calculations (and the key) aren't in the webserver's address space. He confirms that he is indeed trying to write the PKCS#11 dr…

A PKCS#11 driver can simply fork() itself to operate out-of-process, without implementing some sort of heavyweight daemon.

Apache could ship a fall-back PKCS#11 driver implementation that did this, transparently.

Re: Webservers shouldn't have direct access to keys

#55

Post by derefr »

antocv wrote: post #47
derefr wrote: post #42

Earlier quoted context omitted.

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.

I think the change would simply require servers to always send a certificate chain (up to at least the cert's most-proximate global-issuer CA) instead of just a cert. Which is pretty much what every web-scale site does already, to short-circuit OSCP lookups on intermediate CAs.

DNSSEC needn't be involved; you aren't determining whether the CA owns the domain it's issuing certs for at runtime. Instead, the parent-CA who issued the CA's signing cert determined that when they issued the cert. As long as each certificate in the sent chain both 1. checks out as signed by its parent, and 2. has a subject hierarchically below its parent's subject, you can be sure each CA in the chain did whatever it considers diligence before issuing certs to its child-CAs.

Re: Webservers shouldn't have direct access to keys

#56

Post by MichaelGG »

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…

Probably because there's a small market for that? I've met technical people that don't even make their CSRs, they actually have their CA generate private+public keypair so they don't have to figure it out.

Also, CAs make more money if they can issue each leaf cert themselves. Some CAs don't even allow you to get multiple private keys signed (only one active at a time) without paying more.

Re: Webservers shouldn't have direct access to keys

#57

Post by pedrocr »

teacup50 wrote: post #54
pedrocr wrote: post #53

Earlier quoted context omitted.

>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. The OP isn't talking about using an actual HSM, but using a new software based daemon to do the HSM role just so the crypto calculations (and the key) aren't in the webserver's address space. He confirms that he is indeed trying to write the PKCS#11 dr…

A PKCS#11 driver can simply fork() itself to operate out-of-process, without implementing some sort of heavyweight daemon. Apache could ship a fall-back PKCS#11 driver implementation that did this, transparently.

>A PKCS#11 driver can simply fork() itself to operate out-of-process, without implementing some sort of heavyweight daemon.

The OPs proposal was for a daemon so it could be run as a different user. My suggestion was indeed to fork and figure out how to isolate the process (as forking may not be enough if you have permissions to do things like ptrace processes running under the same user).

>Apache could ship a fall-back PKCS#11 driver implementation that did this, transparently.

What you are proposing then is something different. It's to make the only crypto code path the PKCS#11 one and then make the normal case the special case of that. So you are going Apache->Gnutls/OpenSSL->custom PKCS#11 driver->fork->Gnutls/OpenSSL(to actually do the crypto). Since apache already has working code for the first and last steps you could just do Apache->fork->Gnutls/OpenSSL and be done with it. Your suggestion adds more complexity but improves the support for other more exotic PKCS#11 providers.

Re: Webservers shouldn't have direct access to keys

#58

Post by remosi »

pedrocr wrote: post #46
remosi wrote: post #44

Earlier quoted context omitted.

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.

Having looked at PKCS#11, I'm not sure what bits you could get away with not implementing. It does have functions for things like "get random bytes", which I guess you might not want, but that's just barely any code: (int get_random_bytes() { return CKR_NOT_SUPPORTED; }).

All the complexity in this proposal is the serialisation/deserialisation which is about the same amount of work if it's pkcs#11 or some custom thing.

Custom API: Pro: Marginally simpler to implement. Pro: If the webserver fork()'s it by default, then more users get the benefit for the case that you can read the webserver memory. Con: Doesn't protect against attacks that can read files readably by the webserver. Con: Becomes complicated when you want to move to a real HSM. Con: Isn't reusable between webservers, let alone for your mail server, xmpp server, webbrowsers, ssh clients and so on.

Using PKCS#11: Pro: Can start with a PKCS#11 softhsm running as a seperate user today, migrate to hardware HSM with little change tomorrow. Pro: Reusable across multiple webservers, already usable by browsers and ssh clients. Pro: A well defined, maintained, open standard with a wide variety of implementations that already exist. Con: Slightly more complex than a custom protocol, but I'd argue that the custom protocol would grow to cover at least what PKCS#11 supports. I'm currently investigating using dbus for the protocol, so serialisation/deserialisation is mostly taken care of.

Am I missing some Pro for a custom protocol?

Re: Webservers shouldn't have direct access to keys

#59

Post by teacup50 »

pedrocr wrote: post #57
teacup50 wrote: post #54

Earlier quoted context omitted.

A PKCS#11 driver can simply fork() itself to operate out-of-process, without implementing some sort of heavyweight daemon. Apache could ship a fall-back PKCS#11 driver implementation that did this, transparently.

>A PKCS#11 driver can simply fork() itself to operate out-of-process, without implementing some sort of heavyweight daemon. The OPs proposal was for a daemon so it could be run as a different user. My suggestion was indeed to fork and figure out how to isolate the process (as forking may not be enough if you have permissions to do things like ptrace processes running under the same user). >Apache could ship a fall-ba…

After reading your responses and claims of complexity and architecture, I don't think you understand PKCS#11, the problem domain, or the architectural constraints to a level that is commiserate with your expressed level of certainty.

I say this as someone who works on PKCS#11 code: It's not really possible to have a productive conversation with someone that is missing key domain experience and knowledge, but is so certain of their correctness anyway.

More concretely, a forked daemon only needs to support RSA and other crypto operations without revealing their keying material. They don't need a full TLS/SSL stack.

That said, there's absolutely no additional complexity in having both Apache and the hypothetical daemon using a full TLS/SSL crypto library. Any __TEXT pages will be shared, and duplicated __DATA and base-line library allocations are essentially zero.

Re: Webservers shouldn't have direct access to keys

#60

Post by remosi »

teacup50 wrote: post #52
DrStalker wrote: post #51

Earlier quoted context omitted.

That wouldn't help when there is a bug that lets an attacker read your server's memory; you'd still need to reissue your certificates as a preventative measure because you couldn't guarantee that the bit of memory used by the software HSM hadn't been compromised.

The keychain operates out-of-process.

But not out of user. If I can run code as your user, I can attempt to retrieve those keys, although I assume MacOS prevents you from attaching a debugger to the keychain.

Linux has Gnome-keyring, which, amongst other interfaces, operates as a PKCS#11 softhsm (I think), but it still runs as your user.

Post reply on HN