On 06/12/2017 20:25, Michael Wojcik wrote:
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Viktor Dukhovni
Sent: Wednesday, December 06, 2017 13:21
On Dec 6, 2017, at 8:51 AM, Michael Wojcik
<michael.woj...@microfocus.com> wrote:
Note: If you use OpenSSL 1.0.x and you use the DH parameter callback, be
aware that the callback isn't invoked in a useful manner by OpenSSL. (It
always asks for a 1024-bit group, unless an export cipher suite was selected,
which should never happen.)
This is misleading. The callback does not really ask for a 1024-bit group,
rather it passes one of two key-size hints "512" for export ciphers and 1024
for non-export ciphers. Therefore, one can return any reasonable group size
instead of 1024 bits.
Yes, that's what I meant. Sorry if I was unclear. (We have code that still uses
the callback, but passes back a group of size configurable by the
administrator, and defaulting to 2048 bits. As the OpenSSL docs now recommend,
we ignore the size and export parameters to the callback.)
In fact, now that export ciphers have gone the way of the dodo, the best
thing to do is probably just set a single group of your preferred size in all
your
SSL_CTX structures and forget about the callback.
Sure, provided one is sure that this will not lead to (DH) private key re-use.
In sufficiently recent OpenSSL releases single DH use is the default and IIRC
cannot be disabled. But older releases may more reliably avoid DH key re-
use when the group is provided via the tmp_dh callback.
Oh, that's right. There's some option to set to tell OpenSSL 1.0.2 to tell it
not to reuse DH keys, isn't there. Let's see... it's SSL_OP_SINGLE_DH_USE. But
the man page for SSL_CTX_set_tmp_dh and SSL_CTX_set_tmp_dh_callback (and the
SSL-specific versions) seems to imply that SSL_OP_SINGLE_DH_USE isn't necessary
if either of those functions were used.
In any case, since 1.0.2f, SSL_OP_SINGLE_DH_USE is always on and cannot be
disabled (CVE-2016-0701). That's probably why I'd forgotten about it.
In sum: The simplest thing is to choose a single DH group that meets your
requirements (probably at least 2048 bits, and either coming from RFC 7919 or a
good run of openssl dhparam), then set that in each new context with
SLS_CTX_set_tmp_dh.
Actually in some of my code, I have found that the callback can
still be useful by examining the SSL session argument to
heuristically identify likely client side DH size capability and
thus choose between modernDH parameter sizes.
P.S. Forcing use of common DH parameters in TLS 1.3 would directly
make all TLS 1.3 implementations vulnerable to LogJam. That would
be absurd.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
