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
