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? [1]: https://people.canonical.com/~ubuntu- security/cve/2015/CVE-2015-4000.html ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2015-4000 ** Attachment added: "testssl logs of apache and old/new haproxy" https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1841936/+attachment/5291711/+files/testssl-logs.tgz ** Changed in: haproxy (Ubuntu Bionic) Assignee: (unassigned) => Ubuntu Security Team (ubuntu-security) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841936 Title: Rebuild haproxy with openssl 1.1.1 will change features (bionic) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1841936/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
