You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rainer Jung <ra...@kippdata.de> on 2015/05/26 10:33:56 UTC
mod_ssl: Reading dhparams and ecparams not only from the first certificate
file
Current mod_ssl code tries to read embedded DH and ECC parameters only
from the first certificate file. Although this is documented
"DH and ECDH parameters, however, are only read from the first
SSLCertificateFile directive, as they are applied independently of the
authentication algorithm type."
I find it questionable. I would find it more natural to embed the params
in the cert files they apply to, so e.g. the DH params in the RSA cert
file and the EC params in the ECDH cert file and also to not require a
special order for the files which at the end we do not check. Since
missing the embedded params goes unnoticed (finding them is only a DEBUG
log line) it is not very user friendly.
Can't we simply try to read DH and ECC params from every certificate
file and stop in each of the two cases when we have found some? That
would tighten the user unfriendlyness to the case of having multiple
inconsistent parameters embedded in different cert files. And even that
could be checked and logged as a warning.
I would suggest to move the param extraction a little above in the
certificate loop and only try to extract and use the params if a
previous extraction for that type did not already succeed. See below for
a patch suggestion. It moved the read code into the cert loop, removes
the NULL check for certfile (it is done in the loop condition), adds a
boolean dhparams_found and ecparams_found to track whether we already
found some and adds warnings if we find them more than once or if found
ecparams are not valid. The final "auto" behavior setting stays after
the loop and is executed if ecparams is still NULL.
Related is handling of keys embedded in cert files. AFAIK we only try to
read the key from the certificate file instead of a configured key file,
if there is no key file for the same index configured. That means if you
start mixing embedded keys and separate key files, all certificates with
separate key files must come first, then the certificates with the
embedded keys (and the order must match).For this I don't have a better
solution than just documenting it.
Regards,
Rainer
Index: modules/ssl/ssl_engine_init.c
===================================================================
--- modules/ssl/ssl_engine_init.c (revision 1681275)
+++ modules/ssl/ssl_engine_init.c (working copy)
@@ -1039,8 +1039,10 @@
int i;
X509 *cert;
DH *dhparams;
+ int dhparams_found = 0;
#ifdef HAVE_ECC
EC_GROUP *ecparams;
+ int ecparams_found = 0;
int nid;
EC_KEY *eckey = NULL;
#endif
@@ -1174,40 +1176,67 @@
SSL_free(ssl);
#endif
+ /*
+ * Try to read DH parameters from the SSLCertificateFile
+ */
+ dhparams = ssl_dh_GetParamFromFile(certfile);
+ if (dhparams) {
+ if (dhparams_found) {
+ ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
APLOGNO(02901)
+ "Custom DH parameters already loaded for %s,"
+ " ignored from %s",
+ vhost_id, certfile);
+ }
+ else {
+ SSL_CTX_set_tmp_dh(mctx->ssl_ctx, dhparams);
+ dhparams_found = 1;
+ ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(02540)
+ "Custom DH parameters (%d bits) for %s
loaded from %s",
+ BN_num_bits(dhparams->p), vhost_id, certfile);
+ }
+ }
+
+#ifdef HAVE_ECC
+ /*
+ * Try to read the ECDH curve name from SSLCertificateFile
+ */
+ ecparams = ssl_ec_GetParamFromFile(certfile);
+ if (ecparams) {
+ if (ecparams_found) {
+ ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s,
APLOGNO(02902)
+ "Custom ECDH parameters already loaded for
%s,"
+ " ignored from %s",
+ vhost_id, certfile);
+ }
+ else {
+ if ((nid = EC_GROUP_get_curve_name(ecparams)) &&
+ (eckey = EC_KEY_new_by_curve_name(nid))) {
+ SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx, eckey);
+ ecparams_found = 1;
+ ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s,
APLOGNO(02541)
+ "ECDH curve %s for %s specified in %s",
+ OBJ_nid2sn(nid), vhost_id, certfile);
+ }
+ else {
+ ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
APLOGNO(02903)
+ "Invalid ECDH parameters for %s
ignored from %s",
+ vhost_id, certfile);
+ }
+ }
+ }
+#endif
+
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO(02568)
"Certificate and private key %s configured from
%s and %s",
key_id, certfile, keyfile);
}
- /*
- * Try to read DH parameters from the (first) SSLCertificateFile
- */
- if ((certfile = APR_ARRAY_IDX(mctx->pks->cert_files, 0, const char
*)) &&
- (dhparams = ssl_dh_GetParamFromFile(certfile))) {
- SSL_CTX_set_tmp_dh(mctx->ssl_ctx, dhparams);
- ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(02540)
- "Custom DH parameters (%d bits) for %s loaded from
%s",
- BN_num_bits(dhparams->p), vhost_id, certfile);
- }
-
#ifdef HAVE_ECC
/*
- * Similarly, try to read the ECDH curve name from
SSLCertificateFile...
- */
- if ((certfile != NULL) &&
- (ecparams = ssl_ec_GetParamFromFile(certfile)) &&
- (nid = EC_GROUP_get_curve_name(ecparams)) &&
- (eckey = EC_KEY_new_by_curve_name(nid))) {
- SSL_CTX_set_tmp_ecdh(mctx->ssl_ctx, eckey);
- ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(02541)
- "ECDH curve %s for %s specified in %s",
- OBJ_nid2sn(nid), vhost_id, certfile);
- }
- /*
- * ...otherwise, enable auto curve selection (OpenSSL 1.0.2 and later)
+ * If we didn't find any ECDH params, enable auto curve selection
(OpenSSL 1.0.2 and later)
* or configure NIST P-256 (required to enable ECDHE for earlier
versions)
*/
- else {
+ if (!ecparams_found) {
#if defined(SSL_CTX_set_ecdh_auto)
SSL_CTX_set_ecdh_auto(mctx->ssl_ctx, 1);
#else
Index: docs/log-message-tags/next-number
===================================================================
--- docs/log-message-tags/next-number (revision 1681275)
+++ docs/log-message-tags/next-number (working copy)
@@ -1 +1 @@
-2901
+2904
Re: mod_ssl: Reading dhparams and ecparams not only from the first
certificate file
Posted by Rainer Jung <ra...@kippdata.de>.
Am 26.05.2015 um 11:00 schrieb Tim Bannister:
> On 26 May 2015, at 09:37, Reindl Harald <h....@thelounge.net> wrote:
>>
>>
>> Am 26.05.2015 um 10:33 schrieb Rainer Jung:
>>> Current mod_ssl code tries to read embedded DH and ECC parameters only from the first certificate file. Although this is documented
>>>
>>> "DH and ECDH parameters, however, are only read from the first
>>> SSLCertificateFile directive, as they are applied independently of the
>>> authentication algorithm type."
>>>
>>> I find it questionable. I would find it more natural to embed the params in the cert files they apply to, so e.g. the DH params in the RSA cert file and the EC params in the ECDH cert file and also to not require a special order for the files which at the end we do not check. Since missing the embedded params goes unnoticed (finding them is only a DEBUG log line) it is not very user friendly
>>
>> honestly it would be much more user friendly to have a own parameter for that which would make it easy to regenerate the params via cronjobs without touching the PEM file containing the real certificate and private key
>
> With that kind of directive it would also leave flexibility for this kind of thing:
>
> DHParamsEC /tmp/example
> DHParamsEC none
> DHParamsEC auto
>
> (that last case – I'm imagining that httpd generates the D-H parameters at each startup, blocking use of ECDH until generation is complete).
I think the way forward is SSLOpenSSLConfCmd which tries to get rid of
one new mod_ssl directive per new OpenSSL feature. But that is 1.0.2
only. So for a transitory phase we need something else and at least me
I'm happy, that you can already configure the params (by embedding in
the cert file).
Regards,
Rainer
Re: mod_ssl: Reading dhparams and ecparams not only from the first certificate file
Posted by Tim Bannister <is...@c8h10n4o2.org.uk>.
On 26 May 2015, at 09:37, Reindl Harald <h....@thelounge.net> wrote:
>
>
> Am 26.05.2015 um 10:33 schrieb Rainer Jung:
>> Current mod_ssl code tries to read embedded DH and ECC parameters only from the first certificate file. Although this is documented
>>
>> "DH and ECDH parameters, however, are only read from the first
>> SSLCertificateFile directive, as they are applied independently of the
>> authentication algorithm type."
>>
>> I find it questionable. I would find it more natural to embed the params in the cert files they apply to, so e.g. the DH params in the RSA cert file and the EC params in the ECDH cert file and also to not require a special order for the files which at the end we do not check. Since missing the embedded params goes unnoticed (finding them is only a DEBUG log line) it is not very user friendly
>
> honestly it would be much more user friendly to have a own parameter for that which would make it easy to regenerate the params via cronjobs without touching the PEM file containing the real certificate and private key
With that kind of directive it would also leave flexibility for this kind of thing:
DHParamsEC /tmp/example
DHParamsEC none
DHParamsEC auto
(that last case – I'm imagining that httpd generates the D-H parameters at each startup, blocking use of ECDH until generation is complete).
--
Tim Bannister – isoma@c8h10n4o2.org.uk
Re: mod_ssl: Reading dhparams and ecparams not only from the first
certificate file
Posted by Reindl Harald <h....@thelounge.net>.
Am 26.05.2015 um 10:33 schrieb Rainer Jung:
> Current mod_ssl code tries to read embedded DH and ECC parameters only
> from the first certificate file. Although this is documented
>
> "DH and ECDH parameters, however, are only read from the first
> SSLCertificateFile directive, as they are applied independently of the
> authentication algorithm type."
>
> I find it questionable. I would find it more natural to embed the params
> in the cert files they apply to, so e.g. the DH params in the RSA cert
> file and the EC params in the ECDH cert file and also to not require a
> special order for the files which at the end we do not check. Since
> missing the embedded params goes unnoticed (finding them is only a DEBUG
> log line) it is not very user friendly
honestly it would be much more user friendly to have a own parameter for
that which would make it easy to regenerate the params via cronjobs
without touching the PEM file containing the real certificate and
private key
Re: mod_ssl: Reading dhparams and ecparams not only from the first
certificate file
Posted by Rainer Jung <ra...@kippdata.de>.
Am 27.05.2015 um 09:33 schrieb Rainer Jung:
> Am 27.05.2015 um 08:40 schrieb Kaspar Brand:
>> On 26.05.2015 10:33, Rainer Jung wrote:
>>> I find it questionable. I would find it more natural to embed the params
>>> in the cert files they apply to, so e.g. the DH params in the RSA cert
>>> file and the EC params in the ECDH cert file and also to not require a
>>> special order for the files which at the end we do not check. Since
>>> missing the embedded params goes unnoticed (finding them is only a DEBUG
>>> log line) it is not very user friendly.
>>
>> When I added this with r1527295, I didn't expect custom [EC]DH
>> parameters in a certificate file to be the typical case for a mod_ssl
>> configuration - and even in the light of Logjam, I don't think that we
>> would want to recommend creating custom DH parameters for the average
>> admin. As long as 2048-bit RSA keys are configured (the standard for
>> certs issued by publicly-trusted CAs these days), there's nothing wrong
>> with relying on the built-in DH parameters, i.e. those from RFC 3526. [1]
>>
>>> Can't we simply try to read DH and ECC params from every certificate
>>> file and stop in each of the two cases when we have found some? That
>>> would tighten the user unfriendlyness to the case of having multiple
>>> inconsistent parameters embedded in different cert files. And even that
>>> could be checked and logged as a warning.
>>
>> I don't have strong feelings on this, but am not sure if it's worth
>> adding more code to address this specific case. My guess is that
>> multi-cert virtual host configurations with OpenSSL < 1.0.2 are
>> extremely rare, since they are prone to the
>> one-intermediate-CA-cert-only issue, and with OpenSSL 1.0.2 or later,
>> SSLOpenSSLConfCmd is definitely preferrable.
>
> OK
>
>> As far as your observation "to embed the params in the cert files they
>> apply to" is concerned, I think there might be a misunderstanding here:
>> the [EC]DH parameters are orthogonal to the authentication algorithm -
>> for an RSA key, both are applicable (cf. openssl ciphers -v aRSA+DHE and
>> openssl ciphers -v aRSA+ECDHE).
>
> Thanks for the correction.
>
>>> That means if you start mixing embedded keys and separate key files,
>>
>> I would definitely discourage from doing so, and wouldn't bother with
>> adding configuration code to address such cases (would introduce
>> unneeded complexity). Putting the the private key into the
>> SSLCertificateFile has been discouraged since the 2.0 release, actually
>> - see the SSLCertificateKeyFile docs added with r93825. What is probably
>> missing is a more prominent notice in the section on SSLCertificateFile.
>
> OK I'll have a look at the docs an see whether I can improve them.
>
>> [1] The weakdh.org site needs an update on this, as acknowledged by a
>> team member meanwhile, see
>> https://www.ietf.org/mail-archive/web/tls/current/msg16515.html
I edited the mod_ssl docs and faq in r1682923 and r1682937 (trunk),
r1682929 and r1682939 (2.4) and r1682942 (2.2). I hope things are at
least as clear as before my editing.
Regards,
Rainer
Re: mod_ssl: Reading dhparams and ecparams not only from the first
certificate file
Posted by Rainer Jung <ra...@kippdata.de>.
Am 27.05.2015 um 08:40 schrieb Kaspar Brand:
> On 26.05.2015 10:33, Rainer Jung wrote:
>> I find it questionable. I would find it more natural to embed the params
>> in the cert files they apply to, so e.g. the DH params in the RSA cert
>> file and the EC params in the ECDH cert file and also to not require a
>> special order for the files which at the end we do not check. Since
>> missing the embedded params goes unnoticed (finding them is only a DEBUG
>> log line) it is not very user friendly.
>
> When I added this with r1527295, I didn't expect custom [EC]DH
> parameters in a certificate file to be the typical case for a mod_ssl
> configuration - and even in the light of Logjam, I don't think that we
> would want to recommend creating custom DH parameters for the average
> admin. As long as 2048-bit RSA keys are configured (the standard for
> certs issued by publicly-trusted CAs these days), there's nothing wrong
> with relying on the built-in DH parameters, i.e. those from RFC 3526. [1]
>
>> Can't we simply try to read DH and ECC params from every certificate
>> file and stop in each of the two cases when we have found some? That
>> would tighten the user unfriendlyness to the case of having multiple
>> inconsistent parameters embedded in different cert files. And even that
>> could be checked and logged as a warning.
>
> I don't have strong feelings on this, but am not sure if it's worth
> adding more code to address this specific case. My guess is that
> multi-cert virtual host configurations with OpenSSL < 1.0.2 are
> extremely rare, since they are prone to the
> one-intermediate-CA-cert-only issue, and with OpenSSL 1.0.2 or later,
> SSLOpenSSLConfCmd is definitely preferrable.
OK
> As far as your observation "to embed the params in the cert files they
> apply to" is concerned, I think there might be a misunderstanding here:
> the [EC]DH parameters are orthogonal to the authentication algorithm -
> for an RSA key, both are applicable (cf. openssl ciphers -v aRSA+DHE and
> openssl ciphers -v aRSA+ECDHE).
Thanks for the correction.
>> That means if you start mixing embedded keys and separate key files,
>
> I would definitely discourage from doing so, and wouldn't bother with
> adding configuration code to address such cases (would introduce
> unneeded complexity). Putting the the private key into the
> SSLCertificateFile has been discouraged since the 2.0 release, actually
> - see the SSLCertificateKeyFile docs added with r93825. What is probably
> missing is a more prominent notice in the section on SSLCertificateFile.
OK I'll have a look at the docs an see whether I can improve them.
> [1] The weakdh.org site needs an update on this, as acknowledged by a
> team member meanwhile, see
> https://www.ietf.org/mail-archive/web/tls/current/msg16515.html
Thanks for your helpful comments!
Rainer
Re: mod_ssl: Reading dhparams and ecparams not only from the first
certificate file
Posted by Kaspar Brand <ht...@velox.ch>.
On 26.05.2015 10:33, Rainer Jung wrote:
> I find it questionable. I would find it more natural to embed the params
> in the cert files they apply to, so e.g. the DH params in the RSA cert
> file and the EC params in the ECDH cert file and also to not require a
> special order for the files which at the end we do not check. Since
> missing the embedded params goes unnoticed (finding them is only a DEBUG
> log line) it is not very user friendly.
When I added this with r1527295, I didn't expect custom [EC]DH
parameters in a certificate file to be the typical case for a mod_ssl
configuration - and even in the light of Logjam, I don't think that we
would want to recommend creating custom DH parameters for the average
admin. As long as 2048-bit RSA keys are configured (the standard for
certs issued by publicly-trusted CAs these days), there's nothing wrong
with relying on the built-in DH parameters, i.e. those from RFC 3526. [1]
> Can't we simply try to read DH and ECC params from every certificate
> file and stop in each of the two cases when we have found some? That
> would tighten the user unfriendlyness to the case of having multiple
> inconsistent parameters embedded in different cert files. And even that
> could be checked and logged as a warning.
I don't have strong feelings on this, but am not sure if it's worth
adding more code to address this specific case. My guess is that
multi-cert virtual host configurations with OpenSSL < 1.0.2 are
extremely rare, since they are prone to the
one-intermediate-CA-cert-only issue, and with OpenSSL 1.0.2 or later,
SSLOpenSSLConfCmd is definitely preferrable.
As far as your observation "to embed the params in the cert files they
apply to" is concerned, I think there might be a misunderstanding here:
the [EC]DH parameters are orthogonal to the authentication algorithm -
for an RSA key, both are applicable (cf. openssl ciphers -v aRSA+DHE and
openssl ciphers -v aRSA+ECDHE).
> That means if you start mixing embedded keys and separate key files,
I would definitely discourage from doing so, and wouldn't bother with
adding configuration code to address such cases (would introduce
unneeded complexity). Putting the the private key into the
SSLCertificateFile has been discouraged since the 2.0 release, actually
- see the SSLCertificateKeyFile docs added with r93825. What is probably
missing is a more prominent notice in the section on SSLCertificateFile.
Kaspar
[1] The weakdh.org site needs an update on this, as acknowledged by a
team member meanwhile, see
https://www.ietf.org/mail-archive/web/tls/current/msg16515.html