Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl? (was: Re: [PATCH 55593] Add "SSLServerInfoFile" directive)

2013-11-17 Thread Dr Stephen Henson 
On 13/11/2013 14:06, Kaspar Brand wrote:
> 
> I'm not proposing to drop support for encrypted private keys from 2.4.x
> (yet), to be clear - I guess we need to keep this for quite some while
> for backwards compatibility. I suggest, however, to only support
> unencrypted private keys with the "SSLOpenSSLConfCmd PrivateKey"
> directive (in trunk and when backported to 2.4.x), and possibly remove
> support for encrypted private keys for SSLCertificate[Key]File in trunk.
> I.e., I'd be interested in hearing whether people are in favor of (or
> opposition to):
> 
> - only supporting unencrypted private keys with "SSLOpenSSLConfCmd
>   PrivateKey ..."
> 

Just to clarify that. Do you mean that SSLOpenSSLConfCmd shouldn't work with
encrypted private keys at all (e.g. return an error) or that it is just
documented that they might not work as expected?

The SSL_CONF code (which SSLOpenSSLConfCmd uses) should have support for
encrypted private keys as other applications might want to use it. The SSL_CONF
code wasn't designed exclusively for mod_ssl use: though I have to admit I was
partly thinking about how useful it could be in mod_ssl when I wrote it.

Steve.
-- 
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com

Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl? (was: Re: [PATCH 55593] Add "SSLServerInfoFile" directive)

2013-11-13 Thread Dr Stephen Henson 
On 13/11/2013 14:06, Kaspar Brand wrote:
> 
> Taking a step back, however, I wonder what problem we're really solving
> with the support for encrypted private keys. SSLPassPhraseDialog and its
> three incarnations (builtin, pipe and exec) have been in mod_ssl ever
> since 2.0, sure, but what do they actually protect against? Are private
> keys for mod_ssl really still "typically encrypted", as the comment in
> ssl_engine_pphrase.c written in 1998 is telling us?
> 

I can vaguely recall that some of that code is designed to avoid the need to
enter the private key passphrase more than once by decrypting private keys once
and storing the unencrypted forms in serialised form.

Unfortunately it does this in an algorithm specific way which means the whole
lot needs updating every time a new algorithm arrives.

The strategy will also only work for file based keys. If in future you want to
support a key in an HSM it may not be even possible to serialise it. The
"passphrase" may also be outside software control (for example entered into the
device via a pinpad).

Steve.
-- 
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com

Deprecating (and eventually removing) encrypted private key support in mod_ssl? (was: Re: [PATCH 55593] Add "SSLServerInfoFile" directive)

2013-11-13 Thread Kaspar Brand 
On 23.10.2013 16:09, Kaspar Brand wrote:
> On 21.10.2013 06:09, Trevor Perrin wrote:
>> I looked at your patch.  Besides lack of passphrase-handling, it
>> breaks compatibility with existing config files (which assume
>> certs/keys are matched by type, not order).
> 
> I don't think that "random order of multiple SSLCertificateFile and
> SSLCertificateKeyFile directives" is a feature which has ever been
> promised in our docs. In those rare cases where people are currently
> configuring more than one cert per vhost, I would be quite surprised to
> see a config where the order of the SSLCertificateKeyFile directive does
> not match the one of the SSLCertificateFile directives.
> 
>> That would work, but someone would have to rewrite all the
>> passphrase-handling code,
> 
> Correct, and an overhaul of ssl_engine_pphrase.c is actually long due,
> so we shouldn't introduce more band-aid-style workarounds.

Opening a new thread, as the topic isn't related to ServerInfoFile
specifically. While it seams feasible to trim down - and somewhat
repurpose - ssl_pphrase_Handle(), the code would still remain fairly
unwieldy if support for encrypted private keys with "SSLOpenSSLConfCmd
PrivateKey ..." is considered a feature to be preserved.

Taking a step back, however, I wonder what problem we're really solving
with the support for encrypted private keys. SSLPassPhraseDialog and its
three incarnations (builtin, pipe and exec) have been in mod_ssl ever
since 2.0, sure, but what do they actually protect against? Are private
keys for mod_ssl really still "typically encrypted", as the comment in
ssl_engine_pphrase.c written in 1998 is telling us?

Instead of trying to bring up arguments myself, I'll let these two
pieces speak, for the time being:

 http://www.symantec.com/connect/articles/apache-2-ssltls-step-step-part-2
 "Apache 2 with SSL/TLS: Step-by-Step, Part 2", specifically the
 section "The passphrase dilemma"

 http://www.trapkit.de/research/sslkeyfinder/index.html
 http://www.trapkit.de/research/sslkeyfinder/keyfinder_v1.0_20060205.pdf
 "All your private keys are belong to us. Extracting RSA private keys
 and certificates from process memory"

I'm not proposing to drop support for encrypted private keys from 2.4.x
(yet), to be clear - I guess we need to keep this for quite some while
for backwards compatibility. I suggest, however, to only support
unencrypted private keys with the "SSLOpenSSLConfCmd PrivateKey"
directive (in trunk and when backported to 2.4.x), and possibly remove
support for encrypted private keys for SSLCertificate[Key]File in trunk.
I.e., I'd be interested in hearing whether people are in favor of (or
opposition to):

- only supporting unencrypted private keys with "SSLOpenSSLConfCmd
  PrivateKey ..."

- maintain encrypted private key support for SSLCertificate[Key]File,
  but start with marking it as a deprecated (both in trunk and 2.4.x)

Thanks for your opinions and comments.

Kaspar


P.S. As an additional data point: the docs for
SSLProxyMachineCertificateFile have stated "Currently there is no
support for encrypted private keys" since 2004, but people haven't
really been screaming for this feature since then, AFAICT (see also
https://issues.apache.org/bugzilla/show_bug.cgi?id=24031).