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).
