On 11/21/2010 2:38 AM, Stefan Fritsch wrote:
On Sat, 20 Nov 2010, Daniel Ruggeri wrote:
In mod_ssl there is a very handy option of making an exec callout for
SSLPassPhraseDialog rather than to put a password for your private key
in the conf file. The obvious benefit here is that one can then design
a solution to meet any arbitrary number of security challenges before
allowing that password to be delivered.
One of my TODO patches is to add this same functionality in other
places. The first that comes to mind (and something that has pestered
me in the past) is AuthLDAPBindPassword (mod_authnz_ldap). Would
anyone like to suggest other potential places this should be done
before I put together a bug report and send in a patch?
Company policies that require passphrases not to be stored in plaintext
are not that uncommon. Therefore I agree that having a generic
functionality to be used by modules is a good thing.
But IMHO the documentation should be much clearer that this is only
security by obscurity and improves security only in some very limited
areas.
Understood and agreed - I will need to update documentation anyway to
add this functionality and will be willing to drive this point home a
little better.
An attacker who is root on the machine that is running HTTPD can still
get the ssl keys. Either by creating a core dump and extracting the keys
from that (there are tools that do this), or, if the passphrase dialog
yields the passphrases without human interaction, by starting HTTPD
under strace/truss.
Another very valid point - if an attacker has root, you are screwed in
any event.
The only valid use case I see for this feature is to prevent unencrypted
ssl keys from going into the normal backup (if the file with the
passphrases is excluded and is instead backed up on paper). Are there
more valid use cases?
I stewed on this question for a while because I was *sure* I had a good
answer somewhere in my gray matter... but no, I can't really come up
with a solid response to this. If your server admins are putting the
password somewhere safe and using proper file system permissions to
prevent that information from being shared, it's all the same.
I suppose the ideas behind the policies you mention surround the fact
that sometimes people will screw up file system permissions and users on
the host for other purposes (content managers, appserver admins, etc)
could see the password. Or, worse yet, your application is coerced into
reading arbitrary files from the file system. With this in hand, it
allows the security teams as much obscurity as they could fathom.
--
Daniel Ruggeri
