| 2019-08-29 13:35:37 |
David Hedberg |
bug |
|
|
added bug |
| 2019-08-30 06:56:21 |
Christian Ehrhardt |
bug |
|
|
added subscriber Dimitri John Ledkov |
| 2019-08-30 06:58:24 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server |
| 2019-08-30 06:58:30 |
Christian Ehrhardt |
bug |
|
|
added subscriber Christian Ehrhardt |
| 2019-08-30 06:58:34 |
Christian Ehrhardt |
haproxy (Ubuntu): status |
New |
Confirmed |
|
| 2019-08-30 06:58:37 |
Christian Ehrhardt |
haproxy (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-08-30 10:50:41 |
Dimitri John Ledkov |
removed subscriber Dimitri John Ledkov |
|
|
|
| 2019-09-02 06:49:04 |
Christian Ehrhardt |
tags |
|
server-triage-discuss |
|
| 2019-09-03 06:33:15 |
Christian Ehrhardt |
tags |
server-triage-discuss |
|
|
| 2019-09-03 06:33:36 |
Christian Ehrhardt |
summary |
Rebuild haproxy with openssl 1.1.1 (bionic) |
Rebuild haproxy with openssl 1.1.1 will change features (bionic) |
|
| 2019-09-03 06:33:56 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Security Team |
| 2019-09-03 07:18:48 |
Christian Ehrhardt |
haproxy (Ubuntu): status |
Confirmed |
Triaged |
|
| 2019-09-03 07:21:48 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-09-03 07:21:48 |
Christian Ehrhardt |
bug task added |
|
haproxy (Ubuntu Bionic) |
|
| 2019-09-03 07:21:53 |
Christian Ehrhardt |
haproxy (Ubuntu Bionic): status |
New |
Triaged |
|
| 2019-09-03 07:21:55 |
Christian Ehrhardt |
haproxy (Ubuntu): status |
Triaged |
Fix Released |
|
| 2019-09-03 07:21:57 |
Christian Ehrhardt |
haproxy (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2019-09-03 07:21:59 |
Christian Ehrhardt |
haproxy (Ubuntu Bionic): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2019-09-03 07:55:56 |
Christian Ehrhardt |
description |
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 |
[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 fixes
to TLS v1.3 handling [5][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 OTOH nothing of this seems to critical, but
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 |
|
| 2019-09-03 07:58:01 |
Christian Ehrhardt |
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 fixes
to TLS v1.3 handling [5][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 OTOH nothing of this seems to critical, but
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 |
[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 |
|
| 2019-09-03 07:59:33 |
Christian Ehrhardt |
haproxy (Ubuntu Bionic): assignee |
Christian Ehrhardt (paelzer) |
|
|
| 2019-09-26 00:03:38 |
Robie Basak |
haproxy (Ubuntu Bionic): status |
Triaged |
Fix Committed |
|
| 2019-09-26 00:03:39 |
Robie Basak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-09-26 00:03:40 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2019-09-26 00:03:43 |
Robie Basak |
tags |
|
verification-needed verification-needed-bionic |
|
| 2019-09-26 09:32:42 |
Malte Swart |
bug |
|
|
added subscriber Malte Swart |
| 2019-09-27 07:53:59 |
Christian Ehrhardt |
cve linked |
|
2015-4000 |
|
| 2019-09-27 07:53:59 |
Christian Ehrhardt |
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 |
|
| 2019-09-27 07:54:22 |
Christian Ehrhardt |
haproxy (Ubuntu Bionic): assignee |
|
Ubuntu Security Team (ubuntu-security) |
|
| 2019-09-27 10:01:26 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2019-10-08 08:44:06 |
Christian Ehrhardt |
tags |
verification-needed verification-needed-bionic |
server-triage-discuss verification-needed verification-needed-bionic |
|
| 2019-10-08 21:12:29 |
Robie Basak |
tags |
server-triage-discuss verification-needed verification-needed-bionic |
bionic-openssl-1.1 server-triage-discuss verification-needed verification-needed-bionic |
|
| 2019-10-14 13:50:03 |
Christian Ehrhardt |
tags |
bionic-openssl-1.1 server-triage-discuss verification-needed verification-needed-bionic |
bionic-openssl-1.1 verification-failed verification-failed-bionic |
|
| 2019-10-14 14:31:06 |
Christian Ehrhardt |
bug watch added |
|
https://github.com/haproxy/haproxy/issues/324 |
|
| 2019-10-14 14:31:06 |
Christian Ehrhardt |
bug task added |
|
haproxy |
|
| 2019-10-14 16:23:39 |
Bug Watch Updater |
haproxy: status |
Unknown |
New |
|
| 2019-10-22 14:23:01 |
Christian Ehrhardt |
tags |
bionic-openssl-1.1 verification-failed verification-failed-bionic |
bionic-openssl-1.1 server-next verification-failed verification-failed-bionic |
|
| 2019-10-23 00:43:28 |
Bug Watch Updater |
haproxy: status |
New |
Fix Released |
|
| 2019-10-23 08:41:58 |
Christian Ehrhardt |
haproxy (Ubuntu Bionic): assignee |
Ubuntu Security Team (ubuntu-security) |
Christian Ehrhardt (paelzer) |
|
| 2019-10-23 09:45:31 |
Christian Ehrhardt |
haproxy (Ubuntu Bionic): status |
Fix Committed |
In Progress |
|
| 2019-10-23 10:03:30 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Eoan |
|
| 2019-10-23 10:03:30 |
Christian Ehrhardt |
bug task added |
|
haproxy (Ubuntu Eoan) |
|
| 2019-10-23 10:03:30 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Focal |
|
| 2019-10-23 10:03:30 |
Christian Ehrhardt |
bug task added |
|
haproxy (Ubuntu Focal) |
|
| 2019-10-23 10:03:30 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Disco |
|
| 2019-10-23 10:03:30 |
Christian Ehrhardt |
bug task added |
|
haproxy (Ubuntu Disco) |
|
| 2019-10-23 10:03:37 |
Christian Ehrhardt |
haproxy (Ubuntu Eoan): status |
New |
Triaged |
|
| 2019-10-23 10:03:40 |
Christian Ehrhardt |
haproxy (Ubuntu Focal): status |
Fix Released |
Triaged |
|
| 2019-10-23 10:03:42 |
Christian Ehrhardt |
haproxy (Ubuntu Disco): status |
New |
Triaged |
|
| 2019-10-23 10:03:46 |
Christian Ehrhardt |
haproxy (Ubuntu Bionic): status |
In Progress |
Triaged |
|
| 2019-10-23 10:03:48 |
Christian Ehrhardt |
haproxy (Ubuntu Disco): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2019-10-23 10:03:50 |
Christian Ehrhardt |
haproxy (Ubuntu Eoan): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2019-10-23 10:03:51 |
Christian Ehrhardt |
haproxy (Ubuntu Focal): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2019-10-23 10:04:41 |
Christian Ehrhardt |
summary |
Rebuild haproxy with openssl 1.1.1 will change features (bionic) |
Rebuild openssl 1.1.1 to pickup TLSv1.3 (bionic) and unbreak existing builds against 1.1.1 (dh key size) |
|
| 2019-10-23 10:15:05 |
Christian Ehrhardt |
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 |
[Impact-Bionic]
* 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.
[Impact Disco-Focal]
* openssl >=1.1.1 is in Disco-Focal already and thereby it was built
against that already. That made it pick up TLSv1.3, but also a related
bug that broke the ability to control the DHE key, it was always in
"ECDH auto" mode. Therefore the daemon didn't follow the config
anymore.
Upgraders would regress having their DH key behavior changed
unexpectedly.
[Test Case]
* run "haproxy -vv" and check the reported TLS versions to include 1.3
[Regression Potential-Bionic]
* 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.
[Regression Potential-Disco-Focal]
* The fixes let the admin regain control of the DH key configuration
which is the fix. But remember that the default config didn't specify
any. Therefore we have two scenarios:
a) an admin had set custom DH parameters which were ignored. He had no
chance to control them and needs the fix. He might have been under
the impression that his keys are safe (there is a CVE against small
ones) and only now is he really safe -> gain high, regression low
b) an admin had not set anything, the default config is meant to use
(compatibility) and the program reported "I'm using 1024, but you
should set it higher". But what really happened was ECDH auto mode
which has longer keys and different settings. Those systems will
be "fixed" by finally following the config, but that means the key
will "now" after the fix be vulnerable.
-> for their POV a formerly secure setup will become vulnerable
I'd expect that any professional setup would use explicit config as it
has seen the warning since day #1 and also any kind of deployment
recipes should use big keys. So the majority of users should be in (a).
c) And OTOH there are people like the reporter who strictly NEED the
key to be small for their devices they have to support. They will
finally be able to use the small keys again which formerly was
impossible.
Summary: (a) good (c) good, (b) good, but a regression in some POV
[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 |
|
| 2019-10-23 10:17:33 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/haproxy/+git/haproxy/+merge/374589 |
|
| 2019-10-23 10:36:45 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/haproxy/+git/haproxy/+merge/374592 |
|
| 2019-10-23 11:03:14 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/haproxy/+git/haproxy/+merge/374595 |
|
| 2019-10-23 11:04:18 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/haproxy/+git/haproxy/+merge/374596 |
|
| 2019-10-23 11:30:41 |
Christian Ehrhardt |
description |
[Impact-Bionic]
* 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.
[Impact Disco-Focal]
* openssl >=1.1.1 is in Disco-Focal already and thereby it was built
against that already. That made it pick up TLSv1.3, but also a related
bug that broke the ability to control the DHE key, it was always in
"ECDH auto" mode. Therefore the daemon didn't follow the config
anymore.
Upgraders would regress having their DH key behavior changed
unexpectedly.
[Test Case]
* run "haproxy -vv" and check the reported TLS versions to include 1.3
[Regression Potential-Bionic]
* 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.
[Regression Potential-Disco-Focal]
* The fixes let the admin regain control of the DH key configuration
which is the fix. But remember that the default config didn't specify
any. Therefore we have two scenarios:
a) an admin had set custom DH parameters which were ignored. He had no
chance to control them and needs the fix. He might have been under
the impression that his keys are safe (there is a CVE against small
ones) and only now is he really safe -> gain high, regression low
b) an admin had not set anything, the default config is meant to use
(compatibility) and the program reported "I'm using 1024, but you
should set it higher". But what really happened was ECDH auto mode
which has longer keys and different settings. Those systems will
be "fixed" by finally following the config, but that means the key
will "now" after the fix be vulnerable.
-> for their POV a formerly secure setup will become vulnerable
I'd expect that any professional setup would use explicit config as it
has seen the warning since day #1 and also any kind of deployment
recipes should use big keys. So the majority of users should be in (a).
c) And OTOH there are people like the reporter who strictly NEED the
key to be small for their devices they have to support. They will
finally be able to use the small keys again which formerly was
impossible.
Summary: (a) good (c) good, (b) good, but a regression in some POV
[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 |
[Impact-Bionic]
* 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.
[Impact Disco-Focal]
* openssl >=1.1.1 is in Disco-Focal already and thereby it was built
against that already. That made it pick up TLSv1.3, but also a related
bug that broke the ability to control the DHE key, it was always in
"ECDH auto" mode. Therefore the daemon didn't follow the config
anymore.
Upgraders would regress having their DH key behavior changed
unexpectedly.
[Test Case]
A)
* run "haproxy -vv" and check the reported TLS versions to include 1.3
B)
* download https://github.com/drwetter/testssl.sh
* Install haproxy
* ./testssl.sh --pfs <localip>:443
* Check the reported DH key/group (shoudl stay 1024)
* Check if settings work to bump it like
tune.ssl.default-dh-param 2048
into
/etc/haproxy/haproxy.cfg
[Regression Potential-Bionic]
* 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.
[Regression Potential-Disco-Focal]
* The fixes let the admin regain control of the DH key configuration
which is the fix. But remember that the default config didn't specify
any. Therefore we have two scenarios:
a) an admin had set custom DH parameters which were ignored. He had no
chance to control them and needs the fix. He might have been under
the impression that his keys are safe (there is a CVE against small
ones) and only now is he really safe -> gain high, regression low
b) an admin had not set anything, the default config is meant to use
(compatibility) and the program reported "I'm using 1024, but you
should set it higher". But what really happened was ECDH auto mode
which has longer keys and different settings. Those systems will
be "fixed" by finally following the config, but that means the key
will "now" after the fix be vulnerable.
-> for their POV a formerly secure setup will become vulnerable
I'd expect that any professional setup would use explicit config as it
has seen the warning since day #1 and also any kind of deployment
recipes should use big keys. So the majority of users should be in (a).
c) And OTOH there are people like the reporter who strictly NEED the
key to be small for their devices they have to support. They will
finally be able to use the small keys again which formerly was
impossible.
Summary: (a) good (c) good, (b) good, but a regression in some POV
[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 |
|
| 2019-10-28 12:00:05 |
Christian Ehrhardt |
haproxy (Ubuntu Focal): status |
Triaged |
Fix Committed |
|
| 2019-10-28 12:04:28 |
Robie Basak |
haproxy (Ubuntu Eoan): status |
Triaged |
Fix Committed |
|
| 2019-10-28 12:04:32 |
Robie Basak |
tags |
bionic-openssl-1.1 server-next verification-failed verification-failed-bionic |
bionic-openssl-1.1 server-next verification-failed-bionic verification-needed verification-needed-eoan |
|
| 2019-10-28 12:04:51 |
Robie Basak |
haproxy (Ubuntu Disco): status |
Triaged |
Fix Committed |
|
| 2019-10-28 12:04:55 |
Robie Basak |
tags |
bionic-openssl-1.1 server-next verification-failed-bionic verification-needed verification-needed-eoan |
bionic-openssl-1.1 server-next verification-failed-bionic verification-needed verification-needed-disco verification-needed-eoan |
|
| 2019-10-28 12:05:20 |
Robie Basak |
haproxy (Ubuntu Bionic): status |
Triaged |
Fix Committed |
|
| 2019-10-28 12:05:25 |
Robie Basak |
tags |
bionic-openssl-1.1 server-next verification-failed-bionic verification-needed verification-needed-disco verification-needed-eoan |
bionic-openssl-1.1 server-next verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan |
|
| 2019-10-31 07:16:49 |
Christian Ehrhardt |
tags |
bionic-openssl-1.1 server-next verification-needed verification-needed-bionic verification-needed-disco verification-needed-eoan |
bionic-openssl-1.1 server-next verification-done verification-done-bionic verification-done-disco verification-done-eoan |
|
| 2019-10-31 16:36:44 |
Sam |
bug |
|
|
added subscriber Sam |
| 2019-11-04 13:01:07 |
Launchpad Janitor |
haproxy (Ubuntu Eoan): status |
Fix Committed |
Fix Released |
|
| 2019-11-04 13:01:14 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-11-04 13:09:14 |
Launchpad Janitor |
haproxy (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
| 2019-11-04 13:41:40 |
Launchpad Janitor |
haproxy (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-11-06 06:25:08 |
Christian Ehrhardt |
haproxy (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
