On 12/5/2013 6:17 PM, 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. > > 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 :-). > > Also worth noting, other SSL implementations protect their 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... there is no limit to what some > people are willing to do in order to increase their apparent security > posture. > > -- > Daniel Ruggeri >
I don't mean to say that a password protecting the file is "secure"... but it adds a layer, and (most) layers are good. -- Daniel Ruggeri
