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

11–20 of 78 posts

Re: Webservers shouldn't have direct access to keys

#11

Post by phamilton »

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…

They are orthogonal issues. The point of separating private keys is to contain exposure. Heartbleed still would have happened, and all data could be exposed. But right now we not only have to deal with data leakage, but after we patch and fix the bug we have exposure due to the private keys potentially being leaked. We then have to get new certs signed and experience all sorts of additional certs. If the private keyvwas not leaked, then while we still have to deals with the security breach, we can at least avoid having to revoke and reissue all certs.

Re: Webservers shouldn't have direct access to keys

#12

Post by phamilton »

doe88 wrote: post #5

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

Its also similar to an abstraction in Erlang. The crypto application is started and all processes defer to the crypto application for operations. I don't know of the implementation is as secure as the article describes, but the abstraction is simple and straightforward.

Re: Webservers shouldn't have direct access to keys

#13

Post by gingerlime »

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?)

Re: Webservers shouldn't have direct access to keys

#14

Post by hibikir »

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 employees, so that getting a root password is not enough to be able to just take all the credit card information. You don't want the key in any filesystem, and you don't want the key in an easy to retrieve memory location. You end up with servers that require multiple people to boot up, as the keys only really appear when multiple people provide their own piece of the secret.

Eventually, enough security leads to the risk of data loss, as an error can make the keys become unrecoverable.

This is why we have to add security breach detection, and make recovering from a breach easy and having low consequences. Linus said that with enough eyeballs, all buts are shallow. With enough attackers, all systems are insecure.

Re: Webservers shouldn't have direct access to keys

#15

Post by bcoates »

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?

Re: Webservers shouldn't have direct access to keys

#16

Post by teacup50 »

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 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 say for many of the other PKCS standards.

Re: Webservers shouldn't have direct access to keys

#17

Post by nly »

phamilton wrote: post #11
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…

They are orthogonal issues. The point of separating private keys is to contain exposure. Heartbleed still would have happened, and all data could be exposed. But right now we not only have to deal with data leakage, but after we patch and fix the bug we have exposure due to the private keys potentially being leaked. We then have to get new certs signed and experience all sorts of additional certs. If the private keyv…

As long as forward secrecy is/was used then the impact on the individual user is more or less the same. Remember we're largely talking about active MITM.

In the short term your user is compromised whether it's a cookie, an AES key for the TLS session (which will presumably still have to be resident in the process sending you data), a credit card number in a POST request, or your certificate master key.

Anyone who can intercept my traffic in close to real time, and wishes to target me, is going to know I'm talking to amazon.com, IP x.y.z.f, and that that's where they should target their Heartbleed attack for a good stab at accessing my PHP session cookie or TLS session AES key.

There are some cases, like e-mail phishing, where this isn't the case of course... but then a redirection service would be sufficient to let me script an attack against many sites.

Re: Webservers shouldn't have direct access to keys

#18

Post by doe88 »

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?

No need, servers only need to do signature verifications during authentications, thus they only need users/clients public keys which must be listed as authorized_keys.

Edit: I maybe didn't fully grasp you question, if you were referring to ssh host keys, in this case to my knowledge you're right they can not be used with ssh-add.

Re: Webservers shouldn't have direct access to keys

#19

Post by pedrocr »

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

Re: Webservers shouldn't have direct access to keys

#20

Post by erikano »

praseodym wrote: post #6
y0ghur7_xxx wrote: post #2

> Ideally you'd want your TLS keys to be stored in an HSM Does an open spec HSM module exist? I can be somehow sure that linux and apache/nginx don't have backdoors as the source is audited by many people, but I need to be "sure" of my HSM too.

There's an open-source software HSM: http://www.opendnssec.org/softhsm/

Is SoftHSM meant for production use? I get a feeling it's not (but am not lure), based on this sentence:

> You can use it to explore PKCS #11 without having a Hardware Security Module.

Post reply on HN