Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?

[Daniel Ruggeri <DR...@primary.net>]

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

Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?

[Kaspar Brand <ht...@velox.ch>]

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

Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?

[Daniel Ruggeri <DR...@primary.net>]

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