How much protection does this really give? If you manage to hack the web server, then you can quickly feed the HSM/software daemon unlimited amounts of chosen plaintext to encrypt. Would this make it possible to recover the private keys?
Webservers shouldn't have direct access to keys
21–30 of 78 posts
Re: Webservers shouldn't have direct access to keys
#22How much protection does this really give? If you manage to hack the web server, then you can quickly feed the HSM/software daemon unlimited amounts of chosen plaintext to encrypt. Would this make it possible to recover the private keys?
Any encryption algorithm that suffers from chosen plaintext attacks is considered broken.
Re: Webservers shouldn't have direct access to keys
#23Earlier quoted context omitted.
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…
Agreed that the effect on the user is the same, for the most.
It does make my life easier in the event of a vulnerability, with little cost to users. Since I can more efficiently respond, the user arguably gets a better experience.
I agree this doesn't solve everything, but it is a strict improvent over our current system.
Re: Webservers shouldn't have direct access to keys
#24How much protection does this really give? If you manage to hack the web server, then you can quickly feed the HSM/software daemon unlimited amounts of chosen plaintext to encrypt. Would this make it possible to recover the private keys?
Provided that a large enough private key is used, using a "chosen-plaintext attack" (the kind you describe) to obtain the key should be computationally infeasible with known attacks on RSA/DSA/ECDSA.
Much more likely that they'd just hack the web server and MITM you or something.
Re: Webservers shouldn't have direct access to keys
#25Earlier quoted context omitted.
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.
There are several softhsm's, they just share the address space with your frontline daemon which (IMHO) defeats the purpose.
While webserver's support for PKCS#11 is annoying, it's well supported by lots and lots of other stuff (usually client side stuff like ssh, browsers etc tho). You can get webservers to do PKCS#11 today, there are docs on how to do it. They usually start with "download the source, and run configure with this pile of options."
Re: Webservers shouldn't have direct access to keys
#26This 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…
You're right, this doesn't solve 100% of the problem. If I could solve 100% I'd be creating a startup...
Cookies are remarkably sensitive, but they can be far more easily rotated. I can make sure that every cookie is rotated transparently every day or so and leave that running as a sensible background precaution. If we had infrastructure that let us renew our TLS keys every 24 hours or so, this wouldn't be such a big deal (it would still be a big deal, but not quite as bad as it is today). But TLS keys have an expiry of usually years.
Re: Webservers shouldn't have direct access to keys
#27This 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.
Yeah, I was aware of factotum when I wrote this post. GNOME uses p11-kit (which is a wrapper around PKCS#11) and gnome-keyring to kinda provide similar functionality.
Re: Webservers shouldn't have direct access to keys
#28The 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.
Re: Webservers shouldn't have direct access to keys
#29> 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/
It runs in process tho, so it would have had the exact same result with heartbleed. Its keys need to be readable to that user, so exploits like http://blog.detectify.com/post/82370846588/how-we-got-read-a... would also still leak your private keys. So no net win here unfortunately.
opencryptoki has a softhsm too, but again, it appears to run in process. Same problems.
Re: Webservers shouldn't have direct access to keys
#30Wouldn'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 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.