Webservers shouldn't have direct access to keys
plus.google.com
Webservers shouldn't have direct access to keys
1–10 of 78 posts
Re: Webservers shouldn't have direct access to keys
#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.
Re: Webservers shouldn't have direct access to keys
#3This proposal is very similar to Plan 9's "factotum" scheme (see http://qedragon.livejournal.com/99938.html for a nice explanation with reference to Heartbleed; factotum is similar to a generic ssh-agent or gss-proxy), except proposing that the daemon run as a separate user, which is a reasonable extra layer of security that deals with some remote-code exploits.
Re: Webservers shouldn't have direct access to keys
#4This 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 as an unprivileged user. It's probably even possible to do this seamlessly based on the existing SSL config directives in apache/nginx requiring no more intervention from the sysadmin than upgrading to a newer version.
Re: Webservers shouldn't have direct access to keys
#5What is described is something like ssh-agent of openssh.
Re: Webservers shouldn't have direct access to keys
#6> 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/
Re: Webservers shouldn't have direct access to keys
#7This 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. Do you care more about people accessing your Amazon account, and buying things in your name, or people seeing what you're buying? With your Amazon cookies, I can do the former.
So are we all going to jump back to pre-forked, multi-process Apache now, tack on a TLS slave daemon, and ignore gaping big holes in the application layer?
Re: Webservers shouldn't have direct access to keys
#8This 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…
An external standard (de facto or not) is always better when dealing with things like this than a internal API. If I want to reuse that daemon for other things I know what to expect and how to operate it indipendently.
Re: Webservers shouldn't have direct access to keys
#9This 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…
An external standard (de facto or not) is always better when dealing with things like this than a internal API. If I want to reuse that daemon for other things I know what to expect and how to operate it indipendently.
I disagree it's always better. It's a tradeoff. Now to install apache securely you need to go and install another daemon under a different user and configure apache to use it. How many people will actually bother? If it's builtin and driven by apache itself you just need to upgrade apache. So if you want mass adoption of this solution in HTTP servers a builtin solution works best. If you want to be able to reuse this for your openvpn/xmpp/etc server a separate daemon is best.
Re: Webservers shouldn't have direct access to keys
#10[deleted]