On 14.11.2013 12:54, Joe Orton wrote: > I've also always been a sceptic of this (mis)feature, so I hate to be > one to defend it. But demand comes from: > > 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.
Hmm ok, these can be considered (IMO somewhat contrived) use cases, though I think it's possible to suggest workarounds should we decide to completely drop support for encrypted private keys (e.g. exclude the unencrypted key from the backup, and store an encrypted one in parallel / decrypt the encrypted files to a RAM disk and let httpd load them from there and similar). Let me note that that "other" popular open-source HTTP server doesn't have any useful support for encrypted private keys... it will just pop up OpenSSL's default "Enter PEM pass phrase:" prompt (once for each ssl_certificate_key directive, with a single chance of entering the correct pass phrase for each), and on receiving SIGHUP will simply abort the config reload. IOW, lack of support for encrypted private keys does not seem like a "must have" feature for an HTTP server these days. > 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. Oh yes these auditors I like in particular. Probably the same ones who think that not ticking the "Mark this key as exportable" option when importing a key into the Windows cert store does indeed prevent people from extracting them (see https://www.isecpartners.com/tools/application-security/jailbreak.aspx for evidence to the contrary). > I'm most sceptical of all about (b) as motivation for increasing > software complexity, but (a) I can at least appreciate. Does this mean you would object to the eventual removal of support for encrypted private key files in mod_ssl? To get a step further, I put a snapshot of my WIP patch for lifting the "no more than 3 certs/keys" limit with ssl_pphrase_Handle etc. under https://people.apache.org/~kbrand/mod_ssl_pkey_2013-11-17_wip.patch It includes a fairly large number of changes (which I would most likely split into smaller pieces when committing to trunk), but my hope is that other people could give it a try and provide feedback. Brief list of notable changes: - do not index keys by algorithm (use a simple int index) - repurpose ssl_pphrase_Handle as ssl_load_encrypted_pkey (and only use when needed, i.e. when encountering an encrypted key) - change the prompt for the "builtin" dialog to also show the filename (but drop the algorithm type, also for the "exec" dialog) - remove the "myCtxVarGet abomination" (replace with a pphrase_cb_arg_t struct, which currently keeps most of the existing variable names, for the sake of better comparability with the previous code) - move the SSL_CONF_cmd invocations after the ssl_init_server_cert call, so that it can be used as either a complement of the SSLCertificate[Key]File directives, or as a substitute (when including "PrivateKey" and "Certificate" commands) - drop SSL_read_X509 from ssl_util_ssl.c (no longer needed) - remove SGC related bits (SGC has been dead for years) - drop the code for supporting SSLPKCS7CertificateFile (was never documented, either SSLCertificateChainFile and/or SSLCertificateFile serve the same purpose, and a PKCS#7 file can be trivially converted into a file for use with SSLCertificateChainFile) One issue I'm facing with the current implementation is that when relying on SSL_CTX_use_certificate_file/ SSL_CTX_use_certificate_chain_file to configure the cert, there's no way to get at the X509 * which really got configured for the SSL_CTX (remember that we're compiling with OPENSSL_NO_SSL_INTERN for OpenSSL 1.0.0 or later). Steve, could you consider adding SSL_CTX_get_certificate, which would allow retrieving the "current cert" (i.e. one set by the last SSL_CTX_use_certificate* call)? And perhaps SSL_CTX_get_privatekey as its companion, at the same time? Without SSL_CTX_get_certificate at least, we can't call ssl_stapling_init_cert, unfortunately. Feedback would be much appreciated (in particular from people who rely on encrypted keys and could give the patch a try with their existing config). Kaspar
