Generate DH parameters on the fly

[Marco Bambini]

Hello,
my server needs to accept DHE ciphers from clients so I think I would need to be able to load static dh512.pem, dh1024.pem, dh2048.pem and dh4096.pem certificates on server side. In order to increase security I would like to skip the pem file loading step and generate these dh certificates on the fly.

How can I do that?
Which API should I use?

Thanks a lot.
--
Marco Bambini
http://www.sqlabs.com
http://twitter.com/sqlabs
http://instagram.com/sqlabs



______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Dave Thompson]

Sent: Friday, September 19, 2014 12:04
my server needs to accept DHE ciphers from clients so I think I would need

to

be able to load static dh512.pem, dh1024.pem, dh2048.pem and dh4096.pem
certificates on server side. In order to increase security I would like to

skip

the pem file loading step and generate these dh certificates on the fly.

Those aren't certificates, they are parameters. For DHE (and also DH-anon)
server and client each generates a new (ephemeral) keypair for each
handshake
using the same parameters. Having many keypairs under the same parameters
is secure, this is how Diffie-Hellman works. Generating a new keypair is
nearly instantaneous; generating new parameters takes a minute or
several, which would be unacceptable per connection on most servers.
Generating them on server startup, or now and then such as monthly,
would give you the same extremely tiny increase in security.

If you really want that, generate parameters using the DH_ specific
routine or the EVP_PKEY_ wrapper and pass that to set_tmp_dh or
use it (or maybe them) in the callback set by set_tmp_dh_callback,
instead of the one(s) read from file(s).

The protocol does define "static" DH suites which use DH certificates.
(SSLv3 through TLSv1.1 distinguished DH certs signed by RSA or DSS
in the ciphersuite; 1.2 essentially merges them and uses the new
sigalgs extension instead.) OpenSSL did not implement these in any
release yet; 1.0.2 is planned to. DH certificates cannot be requested
using the standard PKCS#10 CSR (because DH can't sign) and I've never
seen nor heard of any CA that issues a DH cert nor any system wanting
to use static-DH. (OpenSSL *does* implement the static *EC*DH suites,
although I haven't seen them used in anger either.)



______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Marco Bambini]

Thanks a lot for the explanation, so instead of generating new parameters on the fly I could just create them once and then load on requests via the SSL_CTX_set_tmp_dh_callback?

Like in the example listed on:
https://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html

Should I provide just 4 files: dh512.pem, dh1024.pem, dh2048.pem, and dh4096.pem?

Please let me know.
Thanks a lot.
--
Marco Bambini
http://www.sqlabs.com
http://twitter.com/sqlabs
http://instagram.com/sqlabs

Post by Dave Thompson

Sent: Friday, September 19, 2014 12:04
my server needs to accept DHE ciphers from clients so I think I would need

to

be able to load static dh512.pem, dh1024.pem, dh2048.pem and dh4096.pem
certificates on server side. In order to increase security I would like to

skip

the pem file loading step and generate these dh certificates on the fly.

Those aren't certificates, they are parameters. For DHE (and also DH-anon)
server and client each generates a new (ephemeral) keypair for each
handshake
using the same parameters. Having many keypairs under the same parameters
is secure, this is how Diffie-Hellman works. Generating a new keypair is
nearly instantaneous; generating new parameters takes a minute or
several, which would be unacceptable per connection on most servers.
Generating them on server startup, or now and then such as monthly,
would give you the same extremely tiny increase in security.
If you really want that, generate parameters using the DH_ specific
routine or the EVP_PKEY_ wrapper and pass that to set_tmp_dh or
use it (or maybe them) in the callback set by set_tmp_dh_callback,
instead of the one(s) read from file(s).
The protocol does define "static" DH suites which use DH certificates.
(SSLv3 through TLSv1.1 distinguished DH certs signed by RSA or DSS
in the ciphersuite; 1.2 essentially merges them and uses the new
sigalgs extension instead.) OpenSSL did not implement these in any
release yet; 1.0.2 is planned to. DH certificates cannot be requested
using the standard PKCS#10 CSR (because DH can't sign) and I've never
seen nor heard of any CA that issues a DH cert nor any system wanting
to use static-DH. (OpenSSL *does* implement the static *EC*DH suites,
although I haven't seen them used in anger either.)
______________________________________________________________________
OpenSSL Project http://www.openssl.org

______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org

[Dave Thompson]

(Sorry, got stuck in my outbox and I didn't notice for a while)

Sent: Monday, September 22, 2014 02:44
Thanks a lot for the explanation, so instead of generating new parameters

on

the fly I could just create them once and then load on requests via the
SSL_CTX_set_tmp_dh_callback?
https://www.openssl.org/docs/ssl/SSL_CTX_set_tmp_dh_callback.html

If you generate one set of parameters you can just set them in set_tmp_dh,
which is specified on the same manpage and is just called before connecting.
The _callback variant is only needed if you want to select different
parameters
for different connections. That example is to support old "export"
ciphersuites
where you are/were required to use DH-512 because of legal restrictions
that no longer apply since about 1999. You should never use export suites
unless you are dealing with very old systems that cannot be upgraded,
in which case it's probably a waste to bother with DHE at all. Even though
OpenSSL does still permit them by default (although based on discussions
here that will probably change in the next release or two).

Should I provide just 4 files: dh512.pem, dh1024.pem, dh2048.pem, and dh4096.pem?

You should use any DH group of size 512 (the supplied file or one you
generate)
only if required for export suites (see above). 512 is now practical to
break.
1024 is adequate for now, although >=2048 provides a better safety margin
and
is specified by standards like NIST SP800-57. However, you should test with
your
clients first; the SSL implementation (JSSE) in Sun-now-Oracle Java before
v8
does not support DH > 1024, and there may be others. If you use 1024 now,
you should have a plan to switch to 2048 or maybe more in a few years.


______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org