** Description changed:

  [impact]
  
  the libtcnative-1 package contains both a dynamic libtcnative-1.so lib,
  as well as a static libtcnative-1.a lib.  Normal java applications will
  use the dynamic library, and it is correctly linked to the system's
  installed libssl library.  However, the static library pulls the build-
  time libssl library in, and so anything using the static libtcnative-1.a
  library will use the build-time libssl version, instead of the currently
  installed libssl library version.
  
  This matters on Bionic since openssl was upgraded from 1.1.0 to 1.1.1;
  the latest libtcnative-1 build was done with the 1.1.0 version of
  libssl, so it does not include TLSv1.3 support, since it has ssl 1.1.0
  built-in.
  
  [test case]
  
  Java typically/historically only loads native libraries dynamically, but JEP 
178 added JVM support for using static libraries:
  https://openjdk.java.net/jeps/178
  
  This is what APR does, and tomcat uses APR, so it pulls in the static
  tcnative-1 library.  This causes the current tomcat9 in Bionic to lack
  support for TLSv1.3.
  
  So, a normal java program can't be used to reproduce/verify this bug -
  it must use APR, like tomcat.
  
  I haven't set up tomcat myself to reproduce and verify this, but the
  reporter of this bug to me uses this connector to enable TLSv1.3 in
  their tomcat deployment, and it fails with the current tcnative-1
  package:
  
  <Connector port="443" protocol="org.apache.coyote.http11.Http11AprProtocol"
  maxThreads="150" SSLEnabled="true" >
  <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
  <SSLHostConfig
  honorCipherOrder="false" protocols="+TLSv1.3,+TLSv1.2"
  
ciphers="TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256"
  disableSessionTickets="true">
  <Certificate certificateKeyFile="/var/lib/tomcat9/casdev.key"
  certificateFile="/var/lib/tomcat9/casdev.crt"
  certificateChainFile="/var/lib/tomcat9/DigiCertCA.crt"
  type="RSA" />
  </SSLHostConfig>
  </Connector>
  
  with a simple no-change rebuild, the tcnative-1 package provides a
  libtcnative-1.a that does provide TLSv1.3 to their tomcat deployment.
  
- 
  [regression potential]
  
  as this is a rebuild-only, any regression would likely impact tomcat9,
  especially in the area of supported TLS/SSL ciphers.
  
  [other info]
  
  This isn't technically a regression, as before OpenSSL was upgraded to
  1.1 in Bionic, tomcat9 didn't provide TLSv1.3 support; but now that
  OpenSSL 1.1 is available in Bionic, tomcat9 should support TLSv1.3.  As
  far as I know, this did not actually introduce any errors/failures for
  anyone currently using tomcat9 with TLSv1.2 or earlier.
  
  I marked this with the tag 'bionic-openssl-1.1' as it falls into the
  group of bugs introduced by the upgrade of openssl from 1.1.0 to 1.1.1.
+ 
+ This affects only Bionic; Xenial doesn't include libssl 1.1, and the latest 
tomcat-native in Disco was built with libssl 1.1.1a:
+ 
https://launchpadlibrarian.net/409281679/buildlog_ubuntu-disco-amd64.tomcat-native_1.2.21-1_BUILDING.txt.gz

** Description changed:

  [impact]
  
  the libtcnative-1 package contains both a dynamic libtcnative-1.so lib,
  as well as a static libtcnative-1.a lib.  Normal java applications will
  use the dynamic library, and it is correctly linked to the system's
  installed libssl library.  However, the static library pulls the build-
  time libssl library in, and so anything using the static libtcnative-1.a
  library will use the build-time libssl version, instead of the currently
  installed libssl library version.
  
  This matters on Bionic since openssl was upgraded from 1.1.0 to 1.1.1;
  the latest libtcnative-1 build was done with the 1.1.0 version of
  libssl, so it does not include TLSv1.3 support, since it has ssl 1.1.0
  built-in.
  
- [test case]
- 
  Java typically/historically only loads native libraries dynamically, but JEP 
178 added JVM support for using static libraries:
  https://openjdk.java.net/jeps/178
  
  This is what APR does, and tomcat uses APR, so it pulls in the static
  tcnative-1 library.  This causes the current tomcat9 in Bionic to lack
  support for TLSv1.3.
  
- So, a normal java program can't be used to reproduce/verify this bug -
- it must use APR, like tomcat.
+ [test case]
+ 
+ A normal java program can't be used to reproduce/verify this bug - it
+ must be something that uses APR, like tomcat, to pull in the static
+ libtcnative-1.a library.
  
  I haven't set up tomcat myself to reproduce and verify this, but the
  reporter of this bug to me uses this connector to enable TLSv1.3 in
  their tomcat deployment, and it fails with the current tcnative-1
  package:
  
  <Connector port="443" protocol="org.apache.coyote.http11.Http11AprProtocol"
  maxThreads="150" SSLEnabled="true" >
  <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
  <SSLHostConfig
  honorCipherOrder="false" protocols="+TLSv1.3,+TLSv1.2"
  
ciphers="TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305,TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256"
  disableSessionTickets="true">
  <Certificate certificateKeyFile="/var/lib/tomcat9/casdev.key"
  certificateFile="/var/lib/tomcat9/casdev.crt"
  certificateChainFile="/var/lib/tomcat9/DigiCertCA.crt"
  type="RSA" />
  </SSLHostConfig>
  </Connector>
  
  with a simple no-change rebuild, the tcnative-1 package provides a
  libtcnative-1.a that does provide TLSv1.3 to their tomcat deployment.
  
  [regression potential]
  
  as this is a rebuild-only, any regression would likely impact tomcat9,
  especially in the area of supported TLS/SSL ciphers.
  
  [other info]
  
  This isn't technically a regression, as before OpenSSL was upgraded to
  1.1 in Bionic, tomcat9 didn't provide TLSv1.3 support; but now that
  OpenSSL 1.1 is available in Bionic, tomcat9 should support TLSv1.3.  As
  far as I know, this did not actually introduce any errors/failures for
  anyone currently using tomcat9 with TLSv1.2 or earlier.
  
  I marked this with the tag 'bionic-openssl-1.1' as it falls into the
  group of bugs introduced by the upgrade of openssl from 1.1.0 to 1.1.1.
  
  This affects only Bionic; Xenial doesn't include libssl 1.1, and the latest 
tomcat-native in Disco was built with libssl 1.1.1a:
  
https://launchpadlibrarian.net/409281679/buildlog_ubuntu-disco-amd64.tomcat-native_1.2.21-1_BUILDING.txt.gz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1854072

Title:
  tomcat-native needs recompile to use TLSv1.3 from openssl 1.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tomcat-native/+bug/1854072/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to