** Description changed: [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. + * 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. + * 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 + 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
-- 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 openssl 1.1.1 to pickup TLSv1.3 (bionic) and unbreak existing builds against 1.1.1 (dh key size) To manage notifications about this bug go to: https://bugs.launchpad.net/haproxy/+bug/1841936/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
