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 High Availability Team, which is subscribed to haproxy in Ubuntu. https://bugs.launchpad.net/bugs/1841936 Title: Rebuild haproxy with openssl 1.1.1 will change features (bionic) Status in haproxy package in Ubuntu: Fix Released Status in haproxy source package in Bionic: Fix Committed Bug description: [Impact] * openssl 1.1.1 has been backported to Bionic for its longer support upstream period * That would allow the extra feature of TLSv1.3 in some consuming packages what seems "for free". Just with a no change rebuild it would pick that up. [Test Case] * run "haproxy -vv" and check the reported TLS versions to include 1.3 [Regression Potential] * This should be low, the code already runs against the .so of the newer openssl library. This would only make it recognize the newer TLS support. i'd expect more trouble as-is with the somewhat big delta between what it was built against vs what it runs with than afterwards. * [1] and [2] indicate that any config that would have been made for TLSv1.2 [1] would not apply to the v1.3 as it would be configured in [2]. It is good to have no entry for [2] yet as following the defaults of openssl is the safest as that would be updated if new insights/CVEs are known. But this could IMHO be the "regression that I'd expect", one explcitly configured the v1.2 things and once both ends support v1.3 that might be auto-negotiated. One can then set "force-tlsv12" but that is an administrative action [3] * Yet AFAIK this fine grained control [2] for TLSv1.3 only exists in >=1.8.15 [4] and Bionic is on haproxy 1.8.8. So any user of TLSv1.3 in Bionic haproxy would have to stay without that. There are further changes to TLS v1.3 handling enhancements [5] but also fixes [6] which aren't in 1.8.8 in Bionic. So one could say enabling this will enable an inferior TLSv1.3 and one might better not enable it, for an SRU the bar to not break old behavior is intentionally high - I tried to provide as much as possible background, the decision is up to the SRU team. [1]: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#3.1-ssl-default-bind-ciphers [2]: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#3.1-ssl-default-bind-ciphersuites [3]: https://www.haproxy.com/documentation/hapee/1-8r2/traffic-management/tls/#define-bind-directives-on-the-frontend [4]: https://github.com/haproxy/haproxy/blob/master/CHANGELOG#L2131 [5]: https://github.com/haproxy/haproxy/commit/526894ff3925d272c13e57926aa6b5d9d8ed5ee3 [6]: https://github.com/haproxy/haproxy/commit/bc34cd1de2ee80de63b5c4d319a501fc0d4ea2f5 [Other Info] * If this is nack'ed we will need an upload that prevents to enable TLSv1.3 to avoid enabling it by accident on e.g. a security update. --- haproxy needs to be rebuilt after #1797386 to take advantage of TLSv1.3. (If that's not desirable for some reason, then maybe TLSv1.3 should be actively disabled to avoid any surprises in case of a future bug fix release.) --- Output of haproxy -vv with stock package: Built with OpenSSL version : OpenSSL 1.1.0g 2 Nov 2017 Running on OpenSSL version : OpenSSL 1.1.1 11 Sep 2018 (VERSIONS DIFFER!) OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 --- Output after rebuilding the package from source: Built with OpenSSL version : OpenSSL 1.1.1 11 Sep 2018 Running on OpenSSL version : OpenSSL 1.1.1 11 Sep 2018 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1841936/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-ha Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-ha More help : https://help.launchpad.net/ListHelp
