I asked tdaitx (java expert) for a quick review: <ddstreet> tdaitx you're the java guy, right? can you review this upload to make sure i got the facts right? it's a simple no-change rebuild, but i don't have experience with tomcat or static JNI libs so would be good to confirm the explanation of why the rebuild is needed is correct <ddstreet> by 'this upload' i meant tomcat-native ^ <ddstreet> from lp #1854072 <ubot5> Launchpad bug 1854072 in tomcat-native (Ubuntu Bionic) "tomcat-native needs recompile to use TLSv1.3 from openssl 1.1" [Medium,In progress] https://launchpad.net/bugs/1854072
<tdaitx> ddstreet: yeah, given the description I supposed it could fix it, whish there was a better way to reproduce it though, I generated the certs, added the commands to tomcat's server.xml (in /etc) but it starts just fine and even lists openssl 1.1.1 (I wonder if it is using the dynamic lib for any reason) <tdaitx> I did a quick look at the libtcnative-1.a and rebuild it on bionic, but haven't seem anything different in symbols and such <ddstreet> tdaitx thanks! ** 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. 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. [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: + I haven't set up tomcat myself, and I'm not familiar enough with it to + know how to set it up to reproduce 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] + The impact section description is based on my limited understanding of + how tomcat9 and APR work to load the libtcnative-1 library; I have not + confirmed that the static libtcnative-1.a lib caches the older libssl + version, but I'm not sure what else in the libtcnative-1 package could + cache the value. The person who reported this to me did confirm that a + simple no-change rebuild of the library fixes this for them. + 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 ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
