Re: A question DH parameter generation and usage

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: A question DH parameter generation and usage

Jakob Bohm-7
On 06/12/2017 07:02, Jayalakshmi bhat wrote:

> Hi,
>
> We are planning to use DHE_RSA TLS ciphers into our product. I have
> few questions on using DH parameter. We would like to use DH-2048.
>
> our product includes both TLS client and server applications. Thus any
> time there will be considerable number of active connectioons.
>
> I believe we can use same DH parameter for all the server connections.
> Is my understanding correct? Is there any risk in using same parameter
> for all the server connections.
>
> Another question is what is guidelines/document should be followed to
> derive DH parameter.
>
> Any input is appreciated.
>
>
In TLS and SSL 3 (current versions, not sure about GoogleTLS 1.3),
DHE parameters are chosen exclusively by the server, so most rules
will be about servers.

Current best practice on clients is to reject parameters of less
than 1000 bits, parameters with fewer bits than they pretend (e.g.
parameters claiming to be 1024 bits, but the most significant 32
bits are all 0, making them really less than 993 bits), parameters
that are glaringly non-prime (e.g. even numbers) and parameters
that cause the DHE calculation to result in an unreasonably number
such as 1 (indicating rigged parameters).  I hope that OpenSSL
client code already does such checks by default, otherwise someone
should point out how to make it do so.

Current best practice on servers is to use DHE parameters such as
those generated by openssl dhparam, or the equivalent API function.

Current best practice on general purpose servers is to use at least
2048 bit DH parameters except when talking to clients that can't do
that, such as the TLS code in Oracle Java 6.  Going above 2048 bits
is good, but some common clients don't work significantly above
that number (for example, some versions of the Mozilla NSS code
have a built in maximum of 2236 bits).

Current best practice on servers is to use DHE parameters that are
used by few other servers, at least in a given timespan.  Thus for
servers that will be deployed in small numbers, just generate your
own parameters at build time using
    openssl dhparam -C xxxx > dhxxxx.inc
then include dhxxxx.inc in your source code.  For servers that will
be deployed in large numbers, load the dh parameters from files in
the format generated by
   openssl dhparam xxxx > dhxxxx.pem
and include scripts or other code that will replace the file
contents daily or weekly (overwriting the old parameters only after
the new ones are ready).  The exim mail server does this if you
follow the instructions.

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
Reply | Threaded
Open this post in threaded view
|

Re: A question DH parameter generation and usage

Jayalakshmi bhat
Hi Jakob and Paul,

Thank you so much for the reply. We have the RSA certificates. I wanted to understand how generally DH parameters are generated. Thanks for the detailed answers.

Regards
Jayalakshmi

On Wed, Dec 6, 2017 at 12:48 AM, Jakob Bohm <[hidden email]> wrote:
On 06/12/2017 07:02, Jayalakshmi bhat wrote:
Hi,

We are planning to use DHE_RSA TLS ciphers into our product. I have few questions on using DH parameter. We would like to use DH-2048.

our product includes both TLS client and server applications. Thus any time there will be considerable number of active connectioons.

I believe we can use same DH parameter for all the server connections. Is my understanding correct? Is there any risk in using same parameter for all the server connections.

Another question is what is guidelines/document should be followed to derive DH parameter.

Any input is appreciated.


In TLS and SSL 3 (current versions, not sure about GoogleTLS 1.3),
DHE parameters are chosen exclusively by the server, so most rules
will be about servers.

Current best practice on clients is to reject parameters of less
than 1000 bits, parameters with fewer bits than they pretend (e.g.
parameters claiming to be 1024 bits, but the most significant 32
bits are all 0, making them really less than 993 bits), parameters
that are glaringly non-prime (e.g. even numbers) and parameters
that cause the DHE calculation to result in an unreasonably number
such as 1 (indicating rigged parameters).  I hope that OpenSSL
client code already does such checks by default, otherwise someone
should point out how to make it do so.

Current best practice on servers is to use DHE parameters such as
those generated by openssl dhparam, or the equivalent API function.

Current best practice on general purpose servers is to use at least
2048 bit DH parameters except when talking to clients that can't do
that, such as the TLS code in Oracle Java 6.  Going above 2048 bits
is good, but some common clients don't work significantly above
that number (for example, some versions of the Mozilla NSS code
have a built in maximum of 2236 bits).

Current best practice on servers is to use DHE parameters that are
used by few other servers, at least in a given timespan.  Thus for
servers that will be deployed in small numbers, just generate your
own parameters at build time using
   openssl dhparam -C xxxx > dhxxxx.inc
then include dhxxxx.inc in your source code.  For servers that will
be deployed in large numbers, load the dh parameters from files in
the format generated by
  openssl dhparam xxxx > dhxxxx.pem
and include scripts or other code that will replace the file
contents daily or weekly (overwriting the old parameters only after
the new ones are ready).  The exim mail server does this if you
follow the instructions.

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


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: A question DH parameter generation and usage

Michael Wojcik
For TLSv1.3, servers are no longer allowed to specify arbitrary DH groups (for finite-field or EC DH). They must use one of the named groups. So for 1.3, there's no point in generating your own groups; conforming implementations can't use them.

For finite-field DH, those are the groups specified by RFC 7919. For ECDH there's a list in the draft TLSv1.3 spec (see section 4.2.8.2), which is available at the usual places.

For TLS prior to 1.3, I agree with Jakob, whose recommendations are essentially the same as the original set coming from the WeakDH researchers. Since the publication of RFC 7919, some people have been recommending using only those groups, because they're believed to be trustworthy; I don't find that a compelling argument. But it's likely that TLSv1.3 (and its successors, presumably continuing the ban on arbitrary groups) will eventually come to dominate, making the question irrelevant in practice.

In short: Use "openssl dhparam" to generate a suitable group or groups, or use the group or groups of appropriate size from RFC 7919. Hard-code these in your server.

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.) 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.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: A question DH parameter generation and usage

Viktor Dukhovni


> On Dec 6, 2017, at 8:51 AM, Michael Wojcik <[hidden email]> 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.  See for example:

   https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_dh.c#L227

where the "1024-bit" group returned by the tmp_dh callback is a 2048-bit group.

The text at:

   http://www.postfix.org/FORWARD_SECRECY_README.html#dfn_fs
   http://www.postfix.org/FORWARD_SECRECY_README.html#tls_fs

may be helpful to some users not familiar with forward secrecy in TLS.


> 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.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: A question DH parameter generation and usage

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Viktor Dukhovni
> Sent: Wednesday, December 06, 2017 13:21
>
> > On Dec 6, 2017, at 8:51 AM, Michael Wojcik
> <[hidden email]> 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.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: A question DH parameter generation and usage

Jakob Bohm-7
On 06/12/2017 20:25, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of Viktor Dukhovni
>> Sent: Wednesday, December 06, 2017 13:21
>>
>>> On Dec 6, 2017, at 8:51 AM, Michael Wojcik
>> <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: A question DH parameter generation and usage

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf
> Of Jakob Bohm
> Sent: Thursday, December 07, 2017 01:44
> >
> 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.

Interesting idea. We might look into doing something similar someday.

> 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.

That's what TLSv1.3 does, as of the latest I-D (and several previous revisions).

Technically, it's not vulnerable to LogJam - LogJam is a downgrade attack, to a 512-bit "export" group, and the smallest group in RFC 7919 is 2048 bits. Using the same parameters across all implementations makes TLSv1.3 theoretically vulnerable to the WeakDH part of the LogJam/WeakDH attack class, but the presumption is that for even well-resourced adversaries a 2048-bit group is intractable. The WeakDH paper suggests breaking a 1024-bit group is feasible, but 2048 is obviously far more expensive. (The exact relationship isn't straightforward to determine, but it's exponential.)

For the paranoid, RFC 7919 / TLSv1.3 give you groups up to 8192 bits.

I am myself not entirely keen on this aspect of TLSv1.3, but this version of TLS has had much more cryptological analysis and engineering than any previous one. I'm sure this issue was discussed at length.

I've seen more than one recommendation to use RFC 7919 groups, rather than arbitrary ones, even for older TLS versions. This is a change from the original WeakDH recommendations. (The "Imperfect Forward Secrecy" paper came out in October 2015, and RFC 7919 in August 2016.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users