On 06.12.2013 01:17, Daniel Ruggeri wrote: > On 11/14/2013 5:54 AM, Joe Orton wrote: >> a) people who want the ability to do filesystem backups without exposing >> private keys to the set of admins who can read such backups; or e.g. >> stick keys on NFS mounts, a similar requirement there. >> >> b) people who like or are required to follow "security by checklist" or >> "security by regulator"; some auditor has "No Plaintext Keys !!!" on the >> checklist, and so we must not use plaintext keys, no argument. >> >> I'm most sceptical of all about (b) as motivation for increasing >> software complexity, but (a) I can at least appreciate. > > c) Like a, the system has lots of users on it that aren't necessarily > trusted (application developers who look at logs) that shouldn't have > access to the key.
In terms of privileges, there isn't much of a difference between a file with an unencrypted private readable by root only, and the fact that the unencrypted key is kept in memory all the time. > d) If any bug/exploit in an application running on the same box or in > httpd is found allowing an arbitrary remote file to be read, an attacker > could easily locate the key (since most httpd.conf files are in > predictable locations) and read it remotely. An even worse case is a > server admin accidentally exposing / due to ignorance and/or malice... > but I can't really defend those guys much :-). If any privilege escalation vulnerability exists on that system, you're in the same situation. Encrypting private keys can't compensate for overall insecurity of the system. > Also worth noting, other SSL implementations protect their keys. I don't think that's true. SSL implementations might offer support for loading encrypted keys, but hardly any of them is programmatically enforcing a particular way of storing private keys. > Java, > for example has a password on the keystore and an optional, additional > password on the key object. I'd say that if the implementation supports > it, httpd should try to accommodate it... That's just how "keytool" works. If a specific utility prompts you for passwords when creating keys, that doesn't say much about how its SSL implementation deals with keys in general. Also, the fact that a library has feature X, option Y or knob Z doesn't necessarily mean that we should continue to maintain lots of unwieldy code (look at ssl_engine_pphrase.c) to make such things sort of usable in mod_ssl. > there is no limit to what some > people are willing to do in order to increase their apparent security > posture. Ok, then I suggest they do something like I briefly outlined in my reply to Joe: "decrypt the encrypted files to a RAM disk and let httpd load them from there" (with all complexity they prefer, such as secret splitting and m-out-of-n authentication etc.). > I don't mean to say that a password protecting the file is "secure"... > but it adds a layer, and (most) layers are good. I don't agree. What you're bringing up is basically the defense in depth argument (which I don't dispute in general), but adding a layer which doesn't really provide additional protection is not only useless, but harmful, since it conveys the wrong message to the user. Kaspar
