httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Ruggeri <>
Subject Re: Removing passwords from the conf file
Date Sun, 21 Nov 2010 12:53:58 GMT

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

View raw message