Hi all,
In my setup (CentOS7, OpenLDAP 2.4.41 from the LDAP Tool Box project) I am using the following slapd.conf parameters for SSL-related configuration:
TLSProtocolMin 3.1 TLSCertificateFile /etc/pki/tls/certs/NNN.crt TLSCertificateKeyFile /etc/pki/tls/private/NNN.key TLSCACertificateFile /etc/pki/tls/certs/NNN.ca.pem TLSDHParamFile /usr/local/openldap/etc/openldap/dh_2048.pem TLSCipherSuite AESGCM:!RSA:!DSS:!ADH:!aECDH
The file /usr/local/openldap/etc/openldap/dh_2048.pem is a valid DH parameter file with size 2048:
<snip> # openssl dh -in /usr/local/openldap/etc/openldap/dh_2048.pem -text -noout PKCS#3 DH Parameters: (2048 bit) prime: </snip>
I am now testing the actual DH parameter size used during a TLS connection with instructions from https://bettercrypto.org/blog/2015/05/20/tls-logjam/ and it only shows DH parameter size 1024:
<snip> $ echo | openssl s_client -connect alias01.alias.ooo:636 -cipher "EDH" 2>/dev/null … much output … No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits </snip>
I was expecting "Server Temp Key: DH, 2048 bits”. Am I just testing this the wrong way or is there an issue with DH parameter configurations in OpenLDAP?
Thanks for any help!
jens
Jens Vagelpohl wrote:
Hi all,
In my setup (CentOS7, OpenLDAP 2.4.41 from the LDAP Tool Box project) I am using the following slapd.conf parameters for SSL-related configuration:
TLSProtocolMin 3.1 TLSCertificateFile /etc/pki/tls/certs/NNN.crt TLSCertificateKeyFile /etc/pki/tls/private/NNN.key TLSCACertificateFile /etc/pki/tls/certs/NNN.ca.pem TLSDHParamFile /usr/local/openldap/etc/openldap/dh_2048.pem TLSCipherSuite AESGCM:!RSA:!DSS:!ADH:!aECDH
The file /usr/local/openldap/etc/openldap/dh_2048.pem is a valid DH parameter file with size 2048:
<snip> # openssl dh -in /usr/local/openldap/etc/openldap/dh_2048.pem -text -noout PKCS#3 DH Parameters: (2048 bit) prime: </snip>
I am now testing the actual DH parameter size used during a TLS connection with instructions from https://bettercrypto.org/blog/2015/05/20/tls-logjam/ and it only shows DH parameter size 1024:
<snip> $ echo | openssl s_client -connect alias01.alias.ooo:636 -cipher "EDH" 2>/dev/null … much output … No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits </snip>
I was expecting "Server Temp Key: DH, 2048 bits”. Am I just testing this the wrong way or is there an issue with DH parameter configurations in OpenLDAP?
Works for me: ### subject=/C=US/ST=California/L=Los Angeles/O=Symas Corporation/OU=Intergalactic HQ/CN=localhost issuer=/C=US/ST=California/O=Symas Corporation/OU=Intergalactic HQ/CN=Symas Keymaster/emailAddress=admin@symas.com --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: DH, 2048 bits --- SSL handshake has read 3177 bytes and written 463 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : DHE-RSA-AES256-GCM-SHA384 ### What is your cert's public key size?
On 14 Jul 2015, at 19:39 , Howard Chu hyc@symas.com wrote:
Jens Vagelpohl wrote:
I am now testing the actual DH parameter size used during a TLS connection with instructions from https://bettercrypto.org/blog/2015/05/20/tls-logjam/ and it only shows DH parameter size 1024:
<snip> $ echo | openssl s_client -connect alias01.alias.ooo:636 -cipher "EDH" 2>/dev/null … much output … No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits </snip>
I was expecting "Server Temp Key: DH, 2048 bits”. Am I just testing this the wrong way or is there an issue with DH parameter configurations in OpenLDAP?
What is your cert's public key size?
Hi Howard,
It’s 4096 bits:
<snip> $ openssl x509 -in /etc/pki/tls/certs/NNN.crt -noout -text … much output … Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: </snip>
jens
Am Tue, 14 Jul 2015 17:25:54 +0200 schrieb Jens Vagelpohl jens@dataflake.org:
Hi all,
In my setup (CentOS7, OpenLDAP 2.4.41 from the LDAP Tool Box project) I am using the following slapd.conf parameters for SSL-related configuration:
TLSProtocolMin 3.1 TLSCertificateFile /etc/pki/tls/certs/NNN.crt TLSCertificateKeyFile /etc/pki/tls/private/NNN.key TLSCACertificateFile /etc/pki/tls/certs/NNN.ca.pem TLSDHParamFile /usr/local/openldap/etc/openldap/dh_2048.pem TLSCipherSuite AESGCM:!RSA:!DSS:!ADH:!aECDH
The file /usr/local/openldap/etc/openldap/dh_2048.pem is a valid DH parameter file with size 2048:
<snip> # openssl dh -in /usr/local/openldap/etc/openldap/dh_2048.pem -text -noout PKCS#3 DH Parameters: (2048 bit) prime: </snip>
I am now testing the actual DH parameter size used during a TLS connection with instructions from https://bettercrypto.org/blog/2015/05/20/tls-logjam/ and it only shows DH parameter size 1024:
<snip> $ echo | openssl s_client -connect alias01.alias.ooo:636 -cipher "EDH" 2>/dev/null … much output … No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: DH, 1024 bits </snip>
I was expecting "Server Temp Key: DH, 2048 bits”. Am I just testing this the wrong way or is there an issue with DH parameter configurations in OpenLDAP?
You may have read this article
https://sys4.de/de/blog/2013/09/09/perfect-forward-secrecy-eine-zusammenfass...
-Dieter
On 15 Jul 2015, at 8:42 , Dieter Klünter dieter@dkluenter.de wrote:
You may have read this article
https://sys4.de/de/blog/2013/09/09/perfect-forward-secrecy-eine-zusammenfass...
Hallo Dieter,
Yes, I have read your article and confirmed again that everything is indeed set up along the lines of your example configuration. The server temporary key remains at 1024 bytes. There is one small difference in the openssl s_client debug output:
<snip> SSL_connect:SSLv3 read server certificate A read from 0x24917f0 [0x24da7d3] (5 bytes => 5 (0x5)) 0000 - 16 03 03 03 0f ..... read from 0x24917f0 [0x24da7d8] (783 bytes => 783 (0x30F)) 0000 - 0c 00 03 0b 00 80 97 f6-42 61 ca b5 05 dd 28 28 ........Ba....(( </snip>
According to your article the ephemeral certificate starts at 0c and "00 02 0b” precedes the certificate length value (here: 00 80, 1024 bits). As you can see, in my case the blocks before the certificate length show "00 03 0b”.
jens
On Wed, Jul 15, 2015 at 08:59:25AM +0200, Jens Vagelpohl wrote:
Yes, I have read your article and confirmed again that everything is indeed set up along the lines of your example configuration. The server temporary key remains at 1024 bytes.
You meant 1024 *bits*
Same here: OpenLDAP was given a 4096 bit DH parameter file, but openssl s_client shows 1024 bits.
This is OpenLDAP 2.4.40. Kernel trace shows the DH parameter file is open, but there is no complain about anything in the logs.
On 15 Jul 2015, at 10:50 , Emmanuel Dreyfus manu@netbsd.org wrote:
On Wed, Jul 15, 2015 at 08:59:25AM +0200, Jens Vagelpohl wrote:
Yes, I have read your article and confirmed again that everything is indeed set up along the lines of your example configuration. The server temporary key remains at 1024 bytes.
You meant 1024 *bits*
Yes, typo, sorry. 1024 bits.
Same here: OpenLDAP was given a 4096 bit DH parameter file, but openssl s_client shows 1024 bits.
This is OpenLDAP 2.4.40. Kernel trace shows the DH parameter file is open, but there is no complain about anything in the logs.
I’m glad it’s not just me then ;-)
jens
On Tue, Jul 14, 2015 at 05:25:54PM +0200, Jens Vagelpohl wrote:
Server Temp Key: DH, 1024 bits
Indeed I confirm OpenLDAP 2.4.40 support for TLSDHParamFile is broken. The problems seems that slapd wants to set the DH parameters through a callback, and I do not see how we can tell OpenSSL what DH parameter length we want in that case. Hence it defaults to 1024 bits.
The attached patch is a first attempt to fix the problem: - set DH parameter for once if they are supplied through TLSDHParamFile, instead of using a callback - Do use SSL_OP_SINGLE_DH_USE (sendmail does that). I do not know whether it should also be used in the callback case. - And while there add the code to support ECDH, it is simple and it does not hurt (This is the same code I contributed to sendmail).
Opinions? Appart that I must file an ITS?
Emmanuel Dreyfus wrote:
On Tue, Jul 14, 2015 at 05:25:54PM +0200, Jens Vagelpohl wrote:
Server Temp Key: DH, 1024 bits
Indeed I confirm OpenLDAP 2.4.40 support for TLSDHParamFile is broken. The problems seems that slapd wants to set the DH parameters through a callback, and I do not see how we can tell OpenSSL what DH parameter length we want in that case. Hence it defaults to 1024 bits.
The attached patch is a first attempt to fix the problem:
- set DH parameter for once if they are supplied through TLSDHParamFile, instead of using a callback
- Do use SSL_OP_SINGLE_DH_USE (sendmail does that). I do not know whether it should also be used in the callback case.
- And while there add the code to support ECDH, it is simple and it does not hurt (This is the same code I contributed to sendmail).
Opinions? Appart that I must file an ITS?
No ITS needed, this code was already rewritten in HEAD, ITS#7506.
On 15 Jul 2015, at 17:35 , Howard Chu hyc@symas.com wrote:
No ITS needed, this code was already rewritten in HEAD, ITS#7506.
Hi Howard,
Since that ITS is several years old I guess the fix is not in OPENLDAP_REL_ENG_2_4?
jens
Jens Vagelpohl wrote:
On 15 Jul 2015, at 17:35 , Howard Chu hyc@symas.com wrote:
No ITS needed, this code was already rewritten in HEAD, ITS#7506.
Hi Howard,
Since that ITS is several years old I guess the fix is not in OPENLDAP_REL_ENG_2_4?
Surely you can read the ITS yourself.
https://www.openldap.org/its/index.cgi/Software Bugs?id=7506
The fix is in 2.5.
On 15 Jul 2015, at 18:07 , Howard Chu hyc@symas.com wrote:
Jens Vagelpohl wrote:
Since that ITS is several years old I guess the fix is not in OPENLDAP_REL_ENG_2_4?
Surely you can read the ITS yourself.
https://www.openldap.org/its/index.cgi/Software Bugs?id=7506
The fix is in 2.5.
Hi Howard,
Yes, I read the ITS but was looking for confirmation because I was surprised this fix was not considered for inclusion in the 2.4 branch.
The issue might have appeared less important back in 2013, but now we have LogJam and DH groups have received proper attention. It would be great if the current release branch of software as important as OpenLDAP would handle those better.
jens
Jens Vagelpohl jens@dataflake.org wrote:
The issue might have appeared less important back in 2013, but now we have LogJam and DH groups have received proper attention. It would be great if the current release branch of software as important as OpenLDAP would handle those better.
Agreed. Admin-supplied DH parameters and ECDH support (because DH > 1024 bits is really slow) are a raising need.
openldap-technical@openldap.org
-
Dieter Klünter -
Emmanuel Dreyfus -
Howard Chu -
Jens Vagelpohl -
manu＠netbsd.org