You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Kaspar Brand <ht...@velox.ch> on 2013/09/15 12:41:21 UTC
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
Re: Streamlining/improving ephemeral key handling in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
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?
Posted by Dr Stephen Henson <sh...@opensslfoundation.com>.
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
shenson@opensslfoundation.com
Re: Streamlining/improving ephemeral key handling in mod_ssl?
Posted by Hanno Böck <ha...@hboeck.de>.
On Mon, 30 Sep 2013 18:40:28 +0200
Kaspar Brand <ht...@velox.ch> 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: hanno@hboeck.de
GPG: BBB51E42
Re: Streamlining/improving ephemeral key handling in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
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?
Posted by Hanno Böck <ha...@hboeck.de>.
On Wed, 25 Sep 2013 07:35:10 +0200
Kaspar Brand <ht...@velox.ch> 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: hanno@hboeck.de
GPG: BBB51E42
Re: Streamlining/improving ephemeral key handling in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
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?
Posted by Joe Orton <jo...@redhat.com>.
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?
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----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?
Posted by Kaspar Brand <ht...@velox.ch>.
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
Re: Streamlining/improving ephemeral key handling in mod_ssl?
Posted by Kaspar Brand <ht...@velox.ch>.
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?
Posted by Erwann Abalea <ea...@gmail.com>.
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 <ht...@velox.ch>
> 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.