Prepped the SRU Template and found a few potential tricky bits while
summarizing, I'll now bring this to the attention of the SRU Team to
make a call.

** Description changed:

+ [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

** Description changed:

  [Impact]
  
-  * openssl 1.1.1 has been backported to Bionic for its longer
-    support upstream period
+  * 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.
+  * 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
+  * 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.
+  * 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.
+ 
+  * 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

** Changed in: haproxy (Ubuntu Bionic)
     Assignee: Christian Ehrhardt  (paelzer) => (unassigned)

-- 
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

Reply via email to