Streamlining/improving ephemeral key handling in mod_ssl?
This grew out of working on a proof of concept for https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 ("Patch to add user-specified Diffie-Hellman parameters"). I would appreciate to get more feedback on the changes proposed with the two attached patches... which is the reason I'm taking the thing to the list. I realized that there's quite some cruft in mod_ssl's ssl_engine_init.c for dealing with ephemeral keys (the MODSSL_TMP_KEY_* macros and their ssl_tmp_key_init_* friends). AFAICT, the primary reason for the whole pTmpKeys dance with SSLModConfigRec at startup was due to the need of pre-generating ephemeral RSA keys (as RSA key generation is an expensive operation). Ephemeral RSA, however, is basically a dead thing: specifically, it was used to weaken the security strength at a time when there were US export restrictions on what was considered "strong" crypto (more than 512 bits for key exchange in the 1990s). These restrictions were lifted many, many years ago - in early 2000, to be precise [1]. I can't think of any good reason to still support export-grade ciphers in 2013 - and if there's a consensus on this, I propose to get rid of ssl_callback_TmpRSA etc. completely (see also [2] for more OpenSSL specific background). For DHE/ECDHE, there's no need to pre-generate keys at startup. In both cases, what is needed are pre-generated *parameters* (from which OpenSSL generates the keys on demand for every new SSL connection, which is a cheap operation, see also [3] and the SSL_OP_SINGLE_DH_USE which mod_ssl unconditionally sets). In sum, I'm thinking of a two-step approach, as demonstrated by the two attached patches (which can be applied to either trunk or 2.4.x). I would be interested in getting feedback on the following points, in particular: - Does anyone object to dropping ephemeral RSA key support (and unconditionally disabling export ciphers), at least for 2.4.x? If so, for what reason? - For the newly-added 2048-bit DH parameters, are there preferences to use another value? (Right now, I took the parameter originally proposed for SKIP - a pre-IKE proposal for IPSec key exchange from 1995. See the comment in ssl_engine_dh.c patch for other potential candidates.) - Are people fine with auto-increasing the DH parameter size to 2048 bits (for certs with RSA or DSA keys of at least 2048 bits)? This will have some negative effects on interop, most likely, but sysadmins could configure custom DH parameters (to downgrade to 1024 bits) as a workaround in this case. Thanks for sharing your thoughts. Reviews/testing of the patches are also very welcome, of course. Kaspar [1] http://epic.org/crypto/export_controls/regs_1_00.html [2] http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_rsa_callback.html#NOTES [3] http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html#NOTES Streamline/improve ephemeral key handling, part 1: - drop support for ephemeral RSA keys (only allowed for export ciphers) and unconditionally disable EXP ciphers - do not configure per-SSL tmp_*_callbacks (use the SSL_CTX instead) - drop pTmpKeys from the per-process SSLModConfigRec, and remove the temp key generation at startup (not needed for DHE/ECDHE) - set default curve for ECDHE at startup (and also configure SSL_OP_SINGLE_ECDH_USE, which was previously left out) Index: ssl_private.h === --- ssl_private.h (revision 1509097) +++ ssl_private.h (working copy) @@ -534,7 +534,6 @@ typedef struct { apr_global_mutex_t *pMutex; apr_array_header_t *aRandSeed; apr_hash_t *tVHostKeys; -void *pTmpKeys[SSL_TMP_KEY_MAX]; /* Two hash tables of pointers to ssl_asn1_t structures. The * structures are used to store certificates and private keys @@ -823,11 +822,7 @@ extern const authz_provider ssl_authz_provider_req extern const authz_provider ssl_authz_provider_verify_client; /** OpenSSL callbacks */ -RSA *ssl_callback_TmpRSA(SSL *, int, int); DH *ssl_callback_TmpDH(SSL *, int, int); -#ifndef OPENSSL_NO_EC -EC_KEY *ssl_callback_TmpECDH(SSL *, int, int); -#endif int ssl_callback_SSLVerify(int, X509_STORE_CTX *); int ssl_callback_SSLVerify_CRL(int, X509_STORE_CTX *, conn_rec *); int ssl_callback_proxy_cert(SSL *ssl, X509 **x509, EVP_PKEY **pkey); Index: mod_ssl.c === --- mod_ssl.c (revision 1509097) +++ mod_ssl.c (working copy) @@ -471,15 +471,6 @@ int ssl_init_ssl_connection(conn_rec *c, request_r sslconn->ssl = ssl; -/* - * Configure callbacks for SSL connection - */ -SSL_set_tmp_rsa_callback(ssl, ssl_callback_TmpRSA); -SSL_set_tmp_dh_callback(ssl, ssl_callback_TmpDH); -#ifndef OPENSSL_NO_EC -SSL_set_tmp_ecdh_callback(ssl, ssl_callback_TmpECDH); -#endif - SSL_set_verify_result(ssl, X509_V_OK); ssl_io_filter_init(c, r, ssl
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On 15/09/2013 11:41, Kaspar Brand wrote: > This grew out of working on a proof of concept for > https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 ("Patch to add > user-specified Diffie-Hellman parameters"). I would appreciate to get > more feedback on the changes proposed with the two attached patches... > which is the reason I'm taking the thing to the list. > A couple of comments. For DH you can get improved server performance by using the length or subprime q. This isn't well supported in currently released versions of OpenSSL unfortunately. For OpenSSL 1.0 and earlier the dh->length parameter can be set. For 1.0.1 and later the subprime value 'q' can be used too (q is included in the structure for previous versions of OpenSSL but not used). The current master branch of OpenSSL supports use of X9.42 DH parameters from a file, that functionality will probably be back ported to (unreleased) 1.0.2. So I'd suggest using parameters where you can set both q and length. For ECDH and released versions of OpenSSL the best that can be currently done is to set the parameters in the server and hope the client supports them (via supported curves extension): if not then ECDSA/ECDH wont be negotiated at all. Use of P-256 is usually safe for this. For OpenSSL 1.0.2 you can just call: SSL_CTX_set_ecdh_auto(ctx, 1); and the most appropriate curve is used automatically. The proposed change doesn't permit finer control of EC parameters: e.g. if it is desired to use non-default curve preferences. While this can be done explicitly at the Apache level I'd suggest instead that the SSL_CONF support code is backported instead: which supports a lot more. If there's anything I can do to help with that let me know. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Streamlining/improving ephemeral key handling in mod_ssl?
Ideally, the second patch should integrate the 2048bits parameters inside the "generated section", and adapt the Perl code accordingly. That way, a paranoid sysadmin can run this file in his perl interpreter, and have his own 512/1024/2048 parameters generated by OpenSSL. You could also decide to remove that possibility once admin-chosen DH parameters become available. I don't really trust these particular parameters, given the current context. See Thomas' response in http://security.stackexchange.com/questions/41941/consequences-of-tampered-etc-ssh-modulifor arguments. Maybe you can consider using some speed-optimized versions of those parameters, with the optional length field added and set to a suitable value? That's what the "-dsaparam" option for the "openssl dhparam" call does. There's no security problem if you use ephemeral keys. 2013/9/15 Kaspar Brand > This grew out of working on a proof of concept for > https://issues.apache.org/bugzilla/show_bug.cgi?id=49559 ("Patch to add > user-specified Diffie-Hellman parameters"). I would appreciate to get > more feedback on the changes proposed with the two attached patches... > which is the reason I'm taking the thing to the list. > > I realized that there's quite some cruft in mod_ssl's ssl_engine_init.c > for dealing with ephemeral keys (the MODSSL_TMP_KEY_* macros and their > ssl_tmp_key_init_* friends). AFAICT, the primary reason for the whole > pTmpKeys dance with SSLModConfigRec at startup was due to the need of > pre-generating ephemeral RSA keys (as RSA key generation is an expensive > operation). > > Ephemeral RSA, however, is basically a dead thing: specifically, it was > used to weaken the security strength at a time when there were US > export restrictions on what was considered "strong" crypto (more than > 512 bits for key exchange in the 1990s). These restrictions were lifted > many, many years ago - in early 2000, to be precise [1]. > > I can't think of any good reason to still support export-grade ciphers > in 2013 - and if there's a consensus on this, I propose to get rid of > ssl_callback_TmpRSA etc. completely (see also [2] for more OpenSSL > specific background). > > For DHE/ECDHE, there's no need to pre-generate keys at startup. In both > cases, what is needed are pre-generated *parameters* (from which OpenSSL > generates the keys on demand for every new SSL connection, which is a > cheap operation, see also [3] and the SSL_OP_SINGLE_DH_USE which mod_ssl > unconditionally sets). > > In sum, I'm thinking of a two-step approach, as demonstrated by the > two attached patches (which can be applied to either trunk or 2.4.x). I > would be interested in getting feedback on the following points, in > particular: > > - Does anyone object to dropping ephemeral RSA key support (and > unconditionally disabling export ciphers), at least for 2.4.x? If so, > for what reason? > > - For the newly-added 2048-bit DH parameters, are there preferences to > use another value? (Right now, I took the parameter originally proposed > for SKIP - a pre-IKE proposal for IPSec key exchange from 1995. See the > comment in ssl_engine_dh.c patch for other potential candidates.) > > - Are people fine with auto-increasing the DH parameter size to 2048 > bits (for certs with RSA or DSA keys of at least 2048 bits)? This will > have some negative effects on interop, most likely, but sysadmins could > configure custom DH parameters (to downgrade to 1024 bits) as a > workaround in this case. > > Thanks for sharing your thoughts. Reviews/testing of the patches are > also very welcome, of course. > > Kaspar > > > [1] http://epic.org/crypto/export_controls/regs_1_00.html > > [2] > http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_rsa_callback.html#NOTES > > [3] http://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html#NOTES > -- Erwann.
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On 15.09.2013 13:17, Dr Stephen Henson wrote: > > A couple of comments. > > For DH you can get improved server performance by using the length or subprime > q. This isn't well supported in currently released versions of OpenSSL > unfortunately. > > For OpenSSL 1.0 and earlier the dh->length parameter can be set. For 1.0.1 and > later the subprime value 'q' can be used too (q is included in the structure > for > previous versions of OpenSSL but not used). The current master branch of > OpenSSL > supports use of X9.42 DH parameters from a file, that functionality will > probably be back ported to (unreleased) 1.0.2. > > So I'd suggest using parameters where you can set both q and length. Thanks. At this time, I was rather focusing on how to configure the DHE parameters, and less on their specific values. If we would take the RFC 5114 values (like OpenSSL 1.0.2 does), then we have values for q. dh->length is set to BN_num_bits(r->q) when a DSA struct is converted into a DH struct (DSA_dup_DH()), but I'm not familiar enough with the underlying crypto to tell whether this approach is feasible in all cases? > For ECDH and released versions of OpenSSL the best that can be currently done > is > to set the parameters in the server and hope the client supports them (via > supported curves extension): if not then ECDSA/ECDH wont be negotiated at all. > Use of P-256 is usually safe for this. > > For OpenSSL 1.0.2 you can just call: > > SSL_CTX_set_ecdh_auto(ctx, 1); > > and the most appropriate curve is used automatically. > > The proposed change doesn't permit finer control of EC parameters: e.g. if it > is > desired to use non-default curve preferences. I think you missed the code after the "Similarly, try to read the ECDHE curve name from SSLCertificateFile" in part 2 of the patch. This allows you to configure a curve other than P-256 (either global or per vhost). > While this can be done explicitly > at the Apache level I'd suggest instead that the SSL_CONF support code is > backported instead: which supports a lot more. If there's anything I can do to > help with that let me know. Long term, that's certainly the better option. Being able to configure a list of curve names would probably be useful (from which OpenSSL would then pick the first which intersects with the elliptic_curves extension from the ClientHello). Kaspar
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On 15.09.2013 15:16, Erwann Abalea wrote: > Ideally, the second patch should integrate the 2048bits parameters inside > the "generated section", and adapt the Perl code accordingly. > That way, a paranoid sysadmin can run this file in his perl interpreter, > and have his own 512/1024/2048 parameters generated by OpenSSL. > You could also decide to remove that possibility once admin-chosen DH > parameters become available. I'm definitely in favor of the latter (not sure how many people really do know that ssl_engine_dh.c can be executed as a Perl script - and if we hardcode DH parameters, I'd rather go for well-defined ones). > I don't really trust these particular parameters, given the current > context. See Thomas' response in > http://security.stackexchange.com/questions/41941/consequences-of-tampered-etc-ssh-modulifor > arguments. Well, referring to the last paragraph of that posting, the 2048-bit parameter included in the patch right now *is* such a "Nothing up my sleeve number" (in contrast to the parameters in RFC 5114, e.g.). See http://tools.ietf.org/html/draft-ietf-ipsec-skip-04#section-6.4.1. > Maybe you can consider using some speed-optimized versions of those > parameters, with the optional length field added and set to a suitable > value? That's what the "-dsaparam" option for the "openssl dhparam" call > does. Yes, but it's a bit more than just adding the length... :-) [see dsa_gen.c:dsa_builtin_paramgen()] > There's no security problem if you use ephemeral keys. True, as long as SSL_OP_SINGLE_DH_USE is set. Kaspar
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On 16.09.2013 07:18, Kaspar Brand wrote: > On 15.09.2013 15:16, Erwann Abalea wrote: >> Ideally, the second patch should integrate the 2048bits parameters inside >> the "generated section", and adapt the Perl code accordingly. >> That way, a paranoid sysadmin can run this file in his perl interpreter, >> and have his own 512/1024/2048 parameters generated by OpenSSL. >> You could also decide to remove that possibility once admin-chosen DH >> parameters become available. > > I'm definitely in favor of the latter (not sure how many people really > do know that ssl_engine_dh.c can be executed as a Perl script - and if > we hardcode DH parameters, I'd rather go for well-defined ones). Attached is an improved version of the second part of the patch, which does the following: - completely drops ssl_engine_dh.c from mod_ssl - relies on DH parameters from RFCs 2407 and 3526 (which are already included as constants in OpenSSL 0.9.8a and later), and configures them in the callback based on the certificate's key length (1024 bits at the minimum, 4096 bits max., currently) - allows admins to configure their own DH parameters via SSLCertificateFile (already implemented with the previous version of the patch), in which case they have precedence over the hardcoded parameters Feedback on this approach is again very welcome. Increasing the minimum required OpenSSL version from 0.9.7 to 0.9.8a shouldn't be of concern, IMO, as 0.9.7 is no longer maintained, and 0.9.8a was released in October 2005 already. Kaspar Streamline/improve ephemeral key handling, part 2, version 2: [to be applied on top of mod_ssl_ekh_part1.diff posted with http://mail-archives.apache.org/mod_mbox/httpd-dev/201309.mbox/%3c52358ed1.2070...@velox.ch%3E] - add well-defined DH parameters (from RFCs 2409 and 3526), and use them based on the length of the certificate's RSA or DSA key - allow to configure custom DHE or ECDHE parameters via the SSLCertificateFile directive - move ssl_dh_GetParamFromFile() from ssl_engine_dh.c to ssl_util_ssl.c, and add ssl_ec_GetParamFromFile() - drop ssl_engine_dh.c from mod_ssl - require OpenSSL 0.9.8a or later Index: ssl_private.h === --- ssl_private.h (revision 1509097) +++ ssl_private.h (working copy) @@ -901,8 +901,10 @@ void ssl_pphrase_Handle(server_rec *, apr_pool_t *); /** Diffie-Hellman Parameter Support */ -DH *ssl_dh_GetTmpParam(int); -DH *ssl_dh_GetParamFromFile(char *); +DH *ssl_dh_GetParamFromFile(const char *); +#ifndef OPENSSL_NO_EC +EC_GROUP *ssl_ec_GetParamFromFile(const char *); +#endif unsigned char *ssl_asn1_table_set(apr_hash_t *table, const char *key, Index: ssl_engine_dh.c === --- ssl_engine_dh.c (revision 1509097) +++ ssl_engine_dh.c (working copy) @@ -1,244 +0,0 @@ -#if 0 -=pod -#endif - -/* Licensed to the Apache Software Foundation (ASF) under one or more - * contributor license agreements. See the NOTICE file distributed with - * this work for additional information regarding copyright ownership. - * The ASF licenses this file to You under the Apache License, Version 2.0 - * (the "License"); you may not use this file except in compliance with - * the License. You may obtain a copy of the License at - * - * http://www.apache.org/licenses/LICENSE-2.0 - * - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - * See the License for the specific language governing permissions and - * limitations under the License. - */ - -/* _ _ - * _ __ ___ ___ __| |___ ___| | mod_ssl - * | '_ ` _ \ / _ \ / _` | / __/ __| | Apache Interface to OpenSSL - * | | | | | | (_) | (_| | \__ \__ \ | - * |_| |_| |_|\___/ \__,_|___|___/___/_| - * |_| - * ssl_engine_dh.c - * Diffie-Hellman Built-in Temporary Parameters - */ - -#include "ssl_private.h" - -/* BEGIN GENERATED SECTION */ - -/* -** Diffie-Hellman-Parameters: (512 bit) -** prime: -** 00:9f:db:8b:8a:00:45:44:f0:04:5f:17:37:d0:ba: -** 2e:0b:27:4c:df:1a:9f:58:82:18:fb:43:53:16:a1: -** 6e:37:41:71:fd:19:d8:d8:f3:7c:39:bf:86:3f:d6: -** 0e:3e:30:06:80:a3:03:0c:6e:4c:37:57:d0:8f:70: -** e6:aa:87:10:33 -** generator: 2 (0x2) -** Diffie-Hellman-Parameters: (1024 bit) -** prime: -** 00:d6:7d:e4:40:cb:bb:dc:19:36:d6:93:d3:4a:fd: -** 0a:d5:0c:84:d2:39:a4:5f:52:0b:b8:81:74:cb:98: -** bc:e9:51:84:9f:91:2e:63:9c:72:fb:13:b4:b4:d7: -** 17:7e:16:d5:5a:c1:79:ba:42:0b:2a:29:fe:32:4a: -** 46:7a:63:5e:81:ff:59:01:37:7b:ed:dc:fd:33:16: -** 8a:46:1a:ad:3b:72:da:e8:86:00:78:0
RE: Streamlining/improving ephemeral key handling in mod_ssl?
> -Original Message- > From: Kaspar Brand > Sent: Sonntag, 22. September 2013 12:32 > To: dev@httpd.apache.org > Subject: Re: Streamlining/improving ephemeral key handling in mod_ssl? > > On 16.09.2013 07:18, Kaspar Brand wrote: > > On 15.09.2013 15:16, Erwann Abalea wrote: > >> Ideally, the second patch should integrate the 2048bits parameters > inside > >> the "generated section", and adapt the Perl code accordingly. > >> That way, a paranoid sysadmin can run this file in his perl > interpreter, > >> and have his own 512/1024/2048 parameters generated by OpenSSL. > >> You could also decide to remove that possibility once admin-chosen DH > >> parameters become available. > > > > I'm definitely in favor of the latter (not sure how many people really > > do know that ssl_engine_dh.c can be executed as a Perl script - and if > > we hardcode DH parameters, I'd rather go for well-defined ones). > > Attached is an improved version of the second part of the patch, which > does the following: > > - completely drops ssl_engine_dh.c from mod_ssl > > - relies on DH parameters from RFCs 2407 and 3526 (which are > already included as constants in OpenSSL 0.9.8a and later), > and configures them in the callback based on the certificate's > key length (1024 bits at the minimum, 4096 bits max., currently) > > - allows admins to configure their own DH parameters via > SSLCertificateFile (already implemented with the previous version > of the patch), in which case they have precedence over the > hardcoded parameters > > Feedback on this approach is again very welcome. Increasing the minimum > required OpenSSL version from 0.9.7 to 0.9.8a shouldn't be of concern, > IMO, as 0.9.7 is no longer maintained, and 0.9.8a was released in > October 2005 already. Approach seems fine to me. I cannot comment on all aspects of the implementation. Maybe you should mention the issues with the Java limitation here. Regards Rüdiger
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On Sun, Sep 22, 2013 at 12:32:23PM +0200, Kaspar Brand wrote: > Feedback on this approach is again very welcome. Increasing the minimum > required OpenSSL version from 0.9.7 to 0.9.8a shouldn't be of concern, > IMO, as 0.9.7 is no longer maintained, and 0.9.8a was released in > October 2005 already. I'd guess this is uncontroversial for trunk, but might be worth flagging up in a separate thread since people did care about 0.9.7 last time we had a poll. Or you could just slip it in and anybody who is not paying attention to dev@ can suffer the consequences ;) I like the idea of overloading the cert file with the DH params. +1, very nice patch. Regards, Joe
Re: Streamlining/improving ephemeral key handling in mod_ssl?
Thanks Joe and Rüdiger for your feedback. I'm going to finish and commit part1 of the patch next (which seems uncontroversial), and wait a few more days for opinions re: OpenSSL 0.9.8a, see also the separate thread. Kaspar
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On Wed, 25 Sep 2013 07:35:10 +0200 Kaspar Brand wrote: > Thanks Joe and Rüdiger for your feedback. I'm going to finish and > commit part1 of the patch next (which seems uncontroversial), and > wait a few more days for opinions re: OpenSSL 0.9.8a, see also the > separate thread. Thanks a lot that there's finally some movement here. What needs to happen so this can be backported to 2.4? Regarding the discussion on ietf-tls happening right now, it'd be a good signal if apache would support larger DH parameters soon. -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On 29.09.2013 19:48, Hanno Böck wrote: > What needs to happen so this can be backported to 2.4? Testing patches and reporting on its results e.g. (as previously solicited in this thread). I have put a backport of the relevant trunk commits under https://people.apache.org/~kbrand/mod_ssl-2.4.x-ekh.diff and will soon add it as a proposal to 2.4.x/STATUS (if my remaining tests with 2.4.6-dev are successful). The backport proposal then needs consensus approval, as explained under http://httpd.apache.org/dev/guidelines.html, so at least two +1 from other devs are needed as well. Kaspar
Re: Streamlining/improving ephemeral key handling in mod_ssl?
On Mon, 30 Sep 2013 18:40:28 +0200 Kaspar Brand wrote: > Testing patches and reporting on its results e.g. (as previously > solicited in this thread). I have put a backport of the relevant trunk > commits under > > https://people.apache.org/~kbrand/mod_ssl-2.4.x-ekh.diff I found that this doesn't apply cleanly on released apache, but it's mostly due to doc rejects. https://svn.schokokeks.org/repos/overlay/trunk/www-servers/apache/files/apache-2.4.6-modssl-dhparams.diff is the patch minus some documentation parts re-diffed against 2.4.6 release. I'm running this now on some test servers (I previously had other preliminaty dh patches from the bugtracker). I like the auto-selection due to rsa key size. Works for me now, I have tested different RSA key sizes on one server and I get different DH moduli: https://www.ssllabs.com/ssltest/analyze.html?d=2048.dosdriver.de https://www.ssllabs.com/ssltest/analyze.html?d=backup1.schokokeks.org No issues so far, so from me: Tested and works. and I'm glad this finally gets some attention. > and will soon add it as a proposal to 2.4.x/STATUS (if my remaining > tests with 2.4.6-dev are successful). The backport proposal then needs > consensus approval, as explained under > http://httpd.apache.org/dev/guidelines.html, so at least two +1 from > other devs are needed as well. I'm not an apache dev, but you get +1 from me for backporting :-) Hanno -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature