Comment 12 for bug 1841936

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