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

71–78 of 78 posts

Re: Webservers shouldn't have direct access to keys

#71

Post by remosi »

dfc wrote: post #69

Has anyone ever used the thinkpad's tpm for anything under linux? Whenever I looked into it the tpm support seemed shoddy especially on my t41. I have not checked the w500 in a long time.

https://www.lorier.net/docs/tpm are my notes with experimenting with the TPM in my T530. The trick is that the TPM will protect itself fairly aggressively, so before you start turn off the laptop, unplug the power and battery (if possible), and on the FIRST boot after you put eveything back together, go into the BIOS and clear the TPM. If the menu option isn't there, then you probably have to power everything off :)

Re: Webservers shouldn't have direct access to keys

#72

Post by teacup50 »

pedrocr wrote: post #68
teacup50 wrote: post #65

Earlier quoted context omitted.

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

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

Yes.

Also, bear in mind that you can't just fork and continue running in modern software.

A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called.

http://pubs.opengroup.org/onlinepubs/009695399/functions/for...

Re: Webservers shouldn't have direct access to keys

#73

Post by DavidSJ »

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.

Perfect security doesn't exist; the goal is to reduce the area of the attack surface. The class of attacks you're talking about is different than the class of attacks an out-of-process keyring protects against.

Re: Webservers shouldn't have direct access to keys

#74

Post by dunham »

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.

OSX keychain runs as root. The user is prompted if an app asks for an entry in the keychain that it has not created the entry and has not explicitly been granted access to the entry

You need root to get at the keys otherwise. There is code to do it here: https://github.com/juuso/keychaindump

(This pulls the key wrapping key out of the process and then decrypts the keychain file directly.)

Re: Webservers shouldn't have direct access to keys

#75

Post by 1amzave »

gingerlime wrote: post #13
doe88 wrote: post #5

What is described is something like ssh-agent of openssh.

My thought exactly. It loads the key into memory and never exposes it, just lets you perform operations such as signing and returns the result. It seems primarily geared at clients rather than servers, but in theory can be used for both (I'm not even sure you can load your openssh server key into ssh-agent, can you?)

> (I'm not even sure you can load your openssh server key into ssh-agent, can you?)

Yes, actually, as of OpenSSH 6.3 you can. (I wrote most of the patch that added that feature.) However, even without doing that the OpenSSH server performs crypto operations in a separate process from the network-facing child process (unless you've disabled UsePrivilegeSeparation). The purpose of having the server talk to an ssh-agent was to allow keeping your host keys encrypted on-disk or loading them from a smart card.

Re: Webservers shouldn't have direct access to keys

#76

Post by callesgg »

remosi wrote: post #67
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 ju…

The content in this scenario is. The http body with banking info or wathever.

Re: Webservers shouldn't have direct access to keys

#77

Post by pedrocr »

teacup50 wrote: post #72
pedrocr wrote: post #68

Earlier quoted context omitted.

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…

> 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. Yes. Also, bear in mind that you can't just fork and continue running in modern software. A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replic…

You'd be forking at the start of the Apache launch before any connections so that shouldn't be much of an issue.

This construct has a much worse bug. It separates the TLS from the rest of apache so it protects against bugs in other parts of the server (HTTP parsing for example) but it doesn't separate the TLS session code from the crypto primitives, so it wouldn't protect against heartbleed. For that forking at the PKCS#11 boundary would be much safer.

Thinking about it a better OpenSSL patch than the Akamai one of protecting the memory with a different alocator would be to run the actual crypto in a different process with a well-defined IPC between that and the main library. That would give you much of the safety of a software HSM without any changes to Apache/nginx or any other TLS server.

Re: Webservers shouldn't have direct access to keys

#78

Post by pedrocr »

pedrocr wrote: post #77
teacup50 wrote: post #72

Earlier quoted context omitted.

> 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. Yes. Also, bear in mind that you can't just fork and continue running in modern software. A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replic…

You'd be forking at the start of the Apache launch before any connections so that shouldn't be much of an issue. This construct has a much worse bug. It separates the TLS from the rest of apache so it protects against bugs in other parts of the server (HTTP parsing for example) but it doesn't separate the TLS session code from the crypto primitives, so it wouldn't protect against heartbleed. For that forking at the P…

Actually, thinking about it some more forking at PKCS#11 driver will not fix heartbleed completely. It will stop the key being recovered but will still allow you to recover passwords and cookies. To fix it completely you'd need forking at both ends, or just using apache in forking instead of event mode.
Post reply on HN