Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 05.01.2014 15:09, Dr Stephen Henson wrote: One the subject of 1.0.2 would it be appropriate to set auto ecdh parameter selection as the default in mod_ssl where supported? As things stand one single curve can be set (with default P-256) and it's an all or nothing choice, with auto parameter selection the highest priority curve supported by both sides is used. For ephemeral keys, you mean? So something like the below in ssl_init_server_certs? I think that would make sense if the admin did not explicitly configure a single curve (together with the Curves SSL_CONF command, this should allow to configure a list of curve names [...] (from which OpenSSL would then pick the first which intersects with the elliptic_curves extension from the ClientHello), as mentioned in [1], right?). Kaspar [1] https://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52369430.3050...@velox.ch%3E --- modules/ssl/ssl_engine_init.c (revision 1555662) +++ modules/ssl/ssl_engine_init.c (working copy) @@ -1020,11 +1020,16 @@ static apr_status_t ssl_init_server_certs(server_r OBJ_nid2sn(nid), vhost_id, certfile); } /* - * ...otherwise, configure NIST P-256 (required to enable ECDHE) + * ...otherwise, enable auto curve selection (OpenSSL 1.0.2 and later) + * or configure NIST P-256 (required to enable ECDHE for earlier versions) */ else { +#if defined(SSL_CTX_set_ecdh_auto) +SSL_CTX_set_ecdh_auto(mctx-ssl_ctx, 1); +#else SSL_CTX_set_tmp_ecdh(mctx-ssl_ctx, EC_KEY_new_by_curve_name(NID_X9_62_prime256v1)); +#endif } #endif
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 03.01.2014 23:51, Dr Stephen Henson wrote: On 28/12/2013 13:34, Kaspar Brand wrote: FYI: in r1553824 (which I just committed to trunk), I'm now manually shuffling things around to support per-cert chains - but would happily drop the #if defined(SSL_CTX_set1_chain)-enclosed code if you decide to adapt SSL_CTX_use_certificate_chain_file in 1.0.2. Now done for OpenSSL master and 1.0.2 branches. Thanks, I have removed the code in r1555463 therefore. Assuming that the release of 1.0.2 isn't too far away by now, I have added a backport proposal for 2.4.x. Votes/reviews welcome. (And while I have your attention: could you perhaps have a look at OpenSSL's PRs #3178 and #3183? Both would help in improving SNI-based configurations.) Kaspar
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 05/01/2014 09:00, Kaspar Brand wrote: On 03.01.2014 23:51, Dr Stephen Henson wrote: On 28/12/2013 13:34, Kaspar Brand wrote: FYI: in r1553824 (which I just committed to trunk), I'm now manually shuffling things around to support per-cert chains - but would happily drop the #if defined(SSL_CTX_set1_chain)-enclosed code if you decide to adapt SSL_CTX_use_certificate_chain_file in 1.0.2. Now done for OpenSSL master and 1.0.2 branches. Thanks, I have removed the code in r1555463 therefore. Assuming that the release of 1.0.2 isn't too far away by now, I have added a backport proposal for 2.4.x. Votes/reviews welcome. (And while I have your attention: could you perhaps have a look at OpenSSL's PRs #3178 and #3183? Both would help in improving SNI-based configurations.) OK I'll have a look at those. One the subject of 1.0.2 would it be appropriate to set auto ecdh parameter selection as the default in mod_ssl where supported? As things stand one single curve can be set (with default P-256) and it's an all or nothing choice, with auto parameter selection the highest priority curve supported by both sides is used. 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?
On 28/12/2013 13:34, Kaspar Brand wrote: On 18.11.2013 18:42, Kaspar Brand wrote: On 18.11.2013 15:38, Dr Stephen Henson wrote: For OpenSSL 1.0.2 this limitation is removed and you can have different chains for each certificate type (and for SSL structures too) and it just uses the right one. This uses the function SSL_CTX_add1_chain_cert which adds a certificate to the chain for the current certificate. I *could* change SSL_CTX_use_certificate_chain_file to use SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have a different function. I'm always cautious about changing the behaviour of existing functions though as the most innocent change will usually break *something*, though I can't see how it can in this case. I would be in favor this change for 1.0.2 - to me that would be more like a fix of SSL_CTX_use_certificate_chain_file than a change in behavior, actually. FYI: in r1553824 (which I just committed to trunk), I'm now manually shuffling things around to support per-cert chains - but would happily drop the #if defined(SSL_CTX_set1_chain)-enclosed code if you decide to adapt SSL_CTX_use_certificate_chain_file in 1.0.2. Now done for OpenSSL master and 1.0.2 branches. 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?
On 18.11.2013 18:42, Kaspar Brand wrote: On 18.11.2013 15:38, Dr Stephen Henson wrote: For OpenSSL 1.0.2 this limitation is removed and you can have different chains for each certificate type (and for SSL structures too) and it just uses the right one. This uses the function SSL_CTX_add1_chain_cert which adds a certificate to the chain for the current certificate. I *could* change SSL_CTX_use_certificate_chain_file to use SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have a different function. I'm always cautious about changing the behaviour of existing functions though as the most innocent change will usually break *something*, though I can't see how it can in this case. I would be in favor this change for 1.0.2 - to me that would be more like a fix of SSL_CTX_use_certificate_chain_file than a change in behavior, actually. FYI: in r1553824 (which I just committed to trunk), I'm now manually shuffling things around to support per-cert chains - but would happily drop the #if defined(SSL_CTX_set1_chain)-enclosed code if you decide to adapt SSL_CTX_use_certificate_chain_file in 1.0.2. Kaspar
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
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?
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?
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
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 17/11/2013 15:25, Dr Stephen Henson wrote: Evil hack workaround: create a temporary SSL structure from the SSL_CTX of interest after you call SSL_CTX_get_certificate, call SSL_get_certificate on it and then free up the temp SSL structure. That *should* work on all the versions of OpenSSL of interest. That's not very efficient and makes me cringe a bit but you'd only go through it once on start up. Erk typo.. I of course meant ...after you call SSL_CTX_use_certificate_file or SSL_CTX_use_certificate_chain_file... A point to note about SSL_CTX_use_certificate_chain_file, at least in its current form. If the certificate file contains additional certificates this will end up adding them to the SSL_CTX using SSL_CTX_add_extra_chain_cert. That is more efficient as it doesn't have to try and build the chain on each call. Unfortunately due to a limitation in OpenSSL 1.0.1 and earlier you can only have one chain for the SSL_CTX shared by all certificate types and all SSL structures created from it. That means if you have more than one certificate configured and they have different chains the second will replace the first in the SSL_CTX and it will end up sending the wrong chain in some cases. For OpenSSL 1.0.2 this limitation is removed and you can have different chains for each certificate type (and for SSL structures too) and it just uses the right one. This uses the function SSL_CTX_add1_chain_cert which adds a certificate to the chain for the current certificate. I *could* change SSL_CTX_use_certificate_chain_file to use SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have a different function. I'm always cautious about changing the behaviour of existing functions though as the most innocent change will usually break *something*, though I can't see how it can in this case. 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?
On 18.11.2013 15:38, Dr Stephen Henson wrote: Erk typo.. I of course meant ...after you call SSL_CTX_use_certificate_file or SSL_CTX_use_certificate_chain_file... Yeah this was obvious... makes me cringe as well but here we go: https://people.apache.org/~kbrand/mod_ssl_pkey_2013-11-18_wip.patch (interdiff attached to this message) For the SSL_CONF_cmd loop, I had to insert a call to ssl_stapling_init_cert as well - currently I'm testing for the Certificate parameter name being set, but if there's a better way to figure out if we need to call ssl_stapling_init_cert, I'm all ears. Unfortunately due to a limitation in OpenSSL 1.0.1 and earlier you can only have one chain for the SSL_CTX shared by all certificate types and all SSL structures created from it. That means if you have more than one certificate configured and they have different chains the second will replace the first in the SSL_CTX and it will end up sending the wrong chain in some cases. Right, that's essentially what the last paragraph of the SSLCertificateChainFile is stating (http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatechainfile), so I wouldn't worry too much about the behavior with releases up to 1.0.1. For OpenSSL 1.0.2 this limitation is removed and you can have different chains for each certificate type (and for SSL structures too) and it just uses the right one. This uses the function SSL_CTX_add1_chain_cert which adds a certificate to the chain for the current certificate. I *could* change SSL_CTX_use_certificate_chain_file to use SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have a different function. I'm always cautious about changing the behaviour of existing functions though as the most innocent change will usually break *something*, though I can't see how it can in this case. I would be in favor this change for 1.0.2 - to me that would be more like a fix of SSL_CTX_use_certificate_chain_file than a change in behavior, actually. Kaspar diff -u trunk/modules/ssl/ssl_engine_init.c trunk/modules/ssl/ssl_engine_init.c --- trunk/modules/ssl/ssl_engine_init.c (working copy) +++ trunk/modules/ssl/ssl_engine_init.c (working copy) @@ -836,6 +836,8 @@ DH *dhparams; ssl_asn1_t *asn1; EVP_PKEY *pkey; +SSL *ssl; +X509 *cert; SSLModConfigRec *mc = myModConfig(s); const char *certfile, *keyfile; @@ -889,31 +891,39 @@ ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO() Certificate and private key #%d for %s do not match, i + 1, vhost_id); -/* - * XXX we can't call ssl_check_public_cert() here, currently, - * as there's no way to get at the X509 * which was configured - * by SSL_CTX_use_certificate_[chain_]file... eventually, we - * would probably want to call: - * ssl_check_public_cert(s, ptemp, cert, i + 1); - */ break; } +/* + * workaround for those OpenSSL versions where SSL_CTX_get_certificate + * is not yet available: create an SSL * which we'll simply throw away + * a few lines further down + */ +if (!(ssl = SSL_new(mctx-ssl_ctx)) || +!(cert = SSL_get_certificate(ssl))) { +ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO() + Unable to retrieve certificate #%d for %s, + i + 1, vhost_id); +if (ssl) +SSL_free(ssl); +break; +} + +/* warn about potential cert issues */ +ssl_check_public_cert(s, ptemp, cert, i + 1); + #ifdef HAVE_OCSP_STAPLING if ((mctx-pkp == FALSE) (mctx-stapling_enabled == TRUE)) { -/* - * XXX can't call ssl_stapling_init_cert currently, for the - * same reason as above with ssl_check_public_cert - * if (!ssl_stapling_init_cert(s, mctx, cert)) { ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(02235) Unable to configure certificate #%d for %s for stapling, i + 1, vhost_id); } - */ } #endif +SSL_free(ssl); + ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO() Certificate and key #%d for %s configured from %s and %s, i + 1, vhost_id, certfile, keyfile); @@ -1189,6 +1199,23 @@ ssl_log_ssl_error(SSLLOG_MARK, APLOG_EMERG, s); ssl_die(s); } +#ifdef HAVE_OCSP_STAPLING +if (!strcasecmp(param-name, Certificate) +sc-server-stapling_enabled == TRUE) { +SSL *ssl; +X509 *cert; +if (!(ssl = SSL_new(sc-server-ssl_ctx)) || +!(cert = SSL_get_certificate(ssl)) || +!ssl_stapling_init_cert(s, sc-server,
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl? (was: Re: [PATCH 55593] Add SSLServerInfoFile directive)
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?
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
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 17.11.2013 15:43, Dr Stephen Henson wrote: On 13/11/2013 14:06, Kaspar Brand wrote: - 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? I'm ok with how it currently behaves. In my WIP patch (see previous message), I'm just disabling the password prompt. The SSL_CONF code (which SSLOpenSSLConfCmd uses) should have support for encrypted private keys as other applications might want to use it. Sure, no problem with that. 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. It's turning out to be quite useful for mod_ssl, and definitely helps in exposing new OpenSSL features to httpd without the need of having to adding new explicit code. Thanks! Kaspar
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 17/11/2013 15:01, Kaspar Brand wrote: 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). I don't think it helps if you don't use OPENSSL_NO_SSL_INTERN either. The actual certificate configured is in a CERT structure (which can be part of SSL_CTX or SSL structures) which is defined in a private header file. 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. I can certainly add functions to OpenSSL 1.0.2 and later, I'd regard it as a useful addition. It's problematical adding it to earlier releases as we have a no new functionality policy for bug fix releases. Evil hack workaround: create a temporary SSL structure from the SSL_CTX of interest after you call SSL_CTX_get_certificate, call SSL_get_certificate on it and then free up the temp SSL structure. That *should* work on all the versions of OpenSSL of interest. That's not very efficient and makes me cringe a bit but you'd only go through it once on start up. 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?
On Thu, Nov 14, 2013 at 07:02:58AM +0100, Kaspar Brand wrote: On 13.11.2013 15:28, Dr Stephen Henson wrote: 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. True, it allows to SIGHUP/SIGUSR1 httpd without having to reenter a passphrase. But my point is a different one, actually: why do we want to enable users to protect file-based keys with a pass phrase in the first place? As the article on the Symantec (formerly Securityfocus) site says: It is not only inconvenient, but also gives a false sense of security. 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. 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. Regards, Joe
Deprecating (and eventually removing) encrypted private key support in mod_ssl? (was: Re: [PATCH 55593] Add SSLServerInfoFile directive)
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).
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl? (was: Re: [PATCH 55593] Add SSLServerInfoFile directive)
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
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 13.11.2013 15:28, Dr Stephen Henson wrote: 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. True, it allows to SIGHUP/SIGUSR1 httpd without having to reenter a passphrase. But my point is a different one, actually: why do we want to enable users to protect file-based keys with a pass phrase in the first place? As the article on the Symantec (formerly Securityfocus) site says: It is not only inconvenient, but also gives a false sense of security. Unfortunately it does this in an algorithm specific way which means the whole lot needs updating every time a new algorithm arrives. That's something we can solve. My current version of ssl_pphrase_Handle() allows configuring as many keys/certs as you see fit (well, it then turns into an OpenSSL issue as you can only have one ECDSA cert e.g., IINM). 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). Correct. I doubt that we would want to add any HSM key activation dance stuff into mod_ssl, this is way too vendor specific. PKCS#11 would be the most sensible thing here, I think, but even in this case, I wonder what benefit passphrase-protected, HSM-based keys would have. Kaspar