Thanks a lot David for testing.
It is important that we track this down and make sure it is not introducing a regression.
The related haproxy config would be:
"tune.ssl.default-dh-param <number>"
Sets the maximum size of the Diffie-Hellman parameters used to generate the ephemeral/temporary Diffie-Hellman key when using DHE key exchange. Default <number> value is 1024. Higher values increase CPU load and may not be supported by some clients (IE:Java 7).
That exactly is our case, and /etc/haproxy/haproxy.cfg hasn't changed.
In the default config this argument isn't set so it should still be 1024.
I set up an apache2 with (self signed) certs and enabled TLS1.0. That is old, but what you reported for your compat needs.
First I tested the apache itself with testssl.sh.
Your output in regard to the DH length seems to be from the PFS section.
I get here:
DH group offered: RFC3526/Oakley Group 14 (2048 bits)
Then I was configuring haproxy+ssl (pre-SRU) in front of apache2 and it gave me
Without the setting above haproxy gives me a nice warning of:
[WARNING] 269/070510 (32043) : Setting tune.ssl.default-dh-param to 1024 by default, if your workload permits it you should set it to at least 2048. Please set a value >= 1024 to make this warning disappear.
In regard to DH length in PFS in testssl both showed me:
DH group offered: HAProxy (1024 bits)
That is just as expected for now.
Upgrading to haproxy from proposed.
The PFS section now really did get bumped, in my case to:
DH group offered: RFC5114/2048-bit DSA group with 224-bit prime order subgroup (2048 bits)
The full diff of old/new haproxy build is
+ TLSv1.3 (good)
+ PFS (critical for the SRU):
- changes cipher list
- extened Elliptic curves
- increased DH size 1024->2048
+ Some noise due to TLSv1.3 (ok)
One diff element also might shows the a potential this increased.
old:
LOGJAM (CVE-2015-4000), experimental VULNERABLE (NOT ok): common prime: HAProxy (1024 bits),
new:
LOGJAM (CVE-2015-4000), experimental common prime with 2048 bits detected: RFC5114/2048-bit DSA group with 224-bit prime order subgroup (2048 bits),
The USN [1] indicated this was solved by disabling "DH EXPORT ciphers", so it shouldn't be a real issue.
But chances are that the newer openssl has a new "minimum DH size" for security reasons in regard to CVE-2015-4000.
Checking workaround by setting an explicit max key in the config ...
=> didn't work still size 2048.
So there is a new minimum in place enforced by the new openssl since/due-to the rebuild.
Attaching the testssl logs ...
@Ubuntu-security: is the bump of offered DH keys something known/expected with rebuilds against the newer OpenSSL for the CVE found or others?
If it is, is this a wanted change considering the breakage of some old clients as reported above?
Thanks a lot David for testing.
It is important that we track this down and make sure it is not introducing a regression.
The related haproxy config would be: default- dh-param <number>"
"tune.ssl.
Sets the maximum size of the Diffie-Hellman parameters used to generate the ephemeral/temporary Diffie-Hellman key when using DHE key exchange. Default <number> value is 1024. Higher values increase CPU load and may not be supported by some clients (IE:Java 7).
That exactly is our case, and /etc/haproxy/ haproxy. cfg hasn't changed.
In the default config this argument isn't set so it should still be 1024.
I set up an apache2 with (self signed) certs and enabled TLS1.0. That is old, but what you reported for your compat needs.
First I tested the apache itself with testssl.sh.
Your output in regard to the DH length seems to be from the PFS section.
I get here:
DH group offered: RFC3526/Oakley Group 14 (2048 bits)
Then I was configuring haproxy+ssl (pre-SRU) in front of apache2 and it gave me
Without the setting above haproxy gives me a nice warning of: default- dh-param to 1024 by default, if your workload permits it you should set it to at least 2048. Please set a value >= 1024 to make this warning disappear.
[WARNING] 269/070510 (32043) : Setting tune.ssl.
In regard to DH length in PFS in testssl both showed me:
DH group offered: HAProxy (1024 bits)
That is just as expected for now.
Upgrading to haproxy from proposed.
The PFS section now really did get bumped, in my case to:
DH group offered: RFC5114/2048-bit DSA group with 224-bit prime order subgroup (2048 bits)
The full diff of old/new haproxy build is
+ TLSv1.3 (good)
+ PFS (critical for the SRU):
- changes cipher list
- extened Elliptic curves
- increased DH size 1024->2048
+ Some noise due to TLSv1.3 (ok)
One diff element also might shows the a potential this increased.
old:
LOGJAM (CVE-2015-4000), experimental VULNERABLE (NOT ok): common prime: HAProxy (1024 bits),
new:
LOGJAM (CVE-2015-4000), experimental common prime with 2048 bits detected: RFC5114/2048-bit DSA group with 224-bit prime order subgroup (2048 bits),
The USN [1] indicated this was solved by disabling "DH EXPORT ciphers", so it shouldn't be a real issue.
But chances are that the newer openssl has a new "minimum DH size" for security reasons in regard to CVE-2015-4000.
Checking workaround by setting an explicit max key in the config ...
=> didn't work still size 2048.
So there is a new minimum in place enforced by the new openssl since/due-to the rebuild.
Attaching the testssl logs ...
@Ubuntu-security: is the bump of offered DH keys something known/expected with rebuilds against the newer OpenSSL for the CVE found or others?
If it is, is this a wanted change considering the breakage of some old clients as reported above?
[1]: https:/ /people. canonical. com/~ubuntu- security/ cve/2015/ CVE-2015- 4000.html