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

61–70 of 78 posts

Re: Webservers shouldn't have direct access to keys

#61

Post by teacup50 »

remosi wrote: post #60
teacup50 wrote: post #52

Earlier quoted context omitted.

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.

Of course. If you can run code as the user, then solutions intended to protect against arbitrary memory read bugs don't apply.

That doesn't mean that the solution is worthless. It simply means that it doesn't cover an unrelated class of bugs.

Migrated to hardware-based tokens, or Intel SGX-protected software tokens, would extend the solution to cover the case of arbitrary code execution. That doesn't eliminate the value of the software-only solution.

Re: Webservers shouldn't have direct access to keys

#62

Post by remosi »

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 would be ideal. One of the problems with heartbleed has been that while you can revoke your cert and mint a new one, browsers don't check CRLs so they'll continue to trust the old compromised cert.

However, I don't think X.509 supports the concept of CA certs being limited to signing only subdomains (could be wrong), and you have a large industry that prefers the status quo of you having to pay them for each cert you mint.

This ends up with ridiculous things like tying payment to the lifetime of the certificate, which allows for things like "2 year certs", which are obviously less secure than 2×1 year certs.

But having your server roll it's cert every 12 hours from a more secure cert elsewhere would be a very nice feature.

Re: Webservers shouldn't have direct access to keys

#63

Post by shuzchen »

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…

How easy it is to hack the server itself really ranges from super simple to extremely hard. Is your target is a home server exposed to the internet, admin'ed by someone who installed apache from following online tutorials? Sure, you're better off just getting root access on the server. However, if your target is a server run by properly trained people who live and breath security practices, your best bet is to use a subtle bug in their stack that escaped their notice, extra bonus if it leaves no audit trail (e.g., heartbleed). I don't think this post is meant for an audience of the former group, but for those of the latter group.

I work at a pretty security conscious company (this might be an understatement, we're pretty big on security), and even as a developer on the inside I'd have to get pretty creative to get access to our production servers.

Re: Webservers shouldn't have direct access to keys

#64

Post by pedrocr »

teacup50 wrote: post #59
pedrocr wrote: post #57

Earlier quoted context omitted.

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

>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'm happy to learn. But all I am saying is that you're adding a PKCS#11 step to the call stack when you can just fork and use the existing code. That's a simple assertion, is it wrong?

>To be a bit more concrete, 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.

I didn't say they did. I said that you had to implement some GnuTLS/OpenSSL code in apache to invoke the PKCS#11 operations, then implement your forking PKCS#11 driver that will then need to call GnuTLS/OpenSSL to do the crypto to return the PKCS#11 results.

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

The complexity I was referring to was in the code that you need to setup the call stack you are proposing. Obviously the gnutls/openssl .so will be shared.

Re: Webservers shouldn't have direct access to keys

#65

Post by teacup50 »

pedrocr wrote: post #64
teacup50 wrote: post #59

Earlier quoted context omitted.

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

>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'm happy to learn. But all I am saying is that you're adding a PKCS#11 step to the call stack when you can just fork and use the existing code. That's a simple assertion, is it wrong?…

> I'm happy to learn. But all I am saying is that you're adding a PKCS#11 step to the call stack when you can just fork and use the existing code. That's a simple assertion, is it wrong?

Yes, that's wrong. What existing code is there that provides an IPC mechanism for offloading RSA signing operations that are done within the TLS libraries themselves?

Re: Webservers shouldn't have direct access to keys

#66

Post by pedrocr »

remosi wrote: post #58
pedrocr wrote: post #46

Earlier quoted context omitted.

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

>Con: Doesn't protect against attacks that can read files readably by the webserver.

This isn't a con for the custom API, it's a con for a forking solution instead of a serialization between two different users.

If PKCS#11 is indeed a good fit for that protocol then it's indeed a much better solution that something custom for the reasons you mention. Good luck with the implementation.

Re: Webservers shouldn't have direct access to keys

#67

Post by remosi »

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.

Your content is often not in the webservers user, it's often stored in a SQL or NoSQL database somewhere. Various access controls can be applied there. But your right, unfortunately this isn't a 100% magic pixie dust solution to everything.

When you say "you can get new keys" which is true (although startssl appears to be the fly in this particular ointment), browsers don't validate CRLs, so the old keys are still just as valid as the new ones. Which makes getting new keys potentially worthless.

This is providing similar protections for your TLS keys to what your database server already applies.

Re: Webservers shouldn't have direct access to keys

#68

Post by pedrocr »

teacup50 wrote: post #65
pedrocr wrote: post #64

Earlier quoted context omitted.

>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'm happy to learn. But all I am saying is that you're adding a PKCS#11 step to the call stack when you can just fork and use the existing code. That's a simple assertion, is it wrong?…

> I'm happy to learn. But all I am saying is that you're adding a PKCS#11 step to the call stack when you can just fork and use the existing code. That's a simple assertion, is it wrong? Yes, that's wrong. What existing code is there that provides an IPC mechanism for offloading RSA signing operations that are done within the TLS libraries themselves?

I see where I've not explained myself properly. The existing code I'm referring to is the code that right now handles the TLS sessions in apache/nginx. That's the code I'm suggesting could be run from a forked process instead of in the main process. To need IPC to offload the RSA crypto you'd need to be doing Apache->TLS session code->fork->RSA operations. I'm saying you could do Apache->fork->TLS session code. Just run all your TLS sessions in a different process with the normal single process, no PKCS#11 GnuTLS/OpenSSL code. Is that not feasible?

To do that Apache needs some form of internal IPC to communicate its TLS sessions to the forked process. Maybe that's more complex than forking and doing IPC at the PKCS#11 driver level? Don't know.

Post reply on HN