On Tue, May 24, 2022 at 3:42 PM Christopher Schultz <ch...@christopherschultz.net> wrote: > > Mark, > > On 5/23/22 14:58, Mark Thomas wrote: > > Hi all, > > > > I've started to look at this and I think we need a slightly broader > > plan. Hence this post to discuss it before I do to much work on it. > > > > It looks like we are going to need to support OpenSSL 1.1.1 in some form > > for quite some time. We are also going to need to support OpenSSL 3.0.x. > > > > Then there is LibreSSL. That appears to have been forked from OpenSSL > > 1.0.2 and hasn't kept completely in sync with subsequent API changes. > > > > I really don't want to have to support what are essentially three > > different APIs to the native SSL library. But I'd like to try and keep > > support for LibreSSL. > > > > Then there is the long term plan to reduce the Native library to the > > minimum required for NIO(2)+OpenSSL. > > > > It appears that LibreSSL does include most/all (TBC) of the API required > > for NIO(2)+OpenSSL. > > > > Given the above I am now thinking about the following plan. > > > > Tomcat Native main becomes 2.0.x where: > > - requires OpenSSL 3.0.x > > - requires APR 1.7.0 (or not at all) > > - can be built with LibreSSL (TBC) > > - drops all the native code apart from that required for NIO(2)+OpenSSL > > - is the minimum Tomcat Native version required by 10.1.x > > - provides FIPS support for 3.0.x > > > > Tomcat Native 1.2.x continues in a (low) maintenance mode > > - No changes to minimum versions > > - Security fixes > > - Releases to pick up newer OpenSSL versions for Windows binaries > > > > My aim would be for it to be possible to use Tomcat Native 2.0.x with > > Tomcat 9.0.x and earlier, provided it was only used for NIO(2)+OpenSSL. > > Trying to use APR or any of the other native code would result in an error. > > > > Optionally, at some point in the future, 1.2.x gets replaced by 1.3.x > > that increases minimum versions to OpenSSL 1.1.1 and APR 1.6.3. I'm not > > sure about this and what it means for OpenSSL 1.x and FIPS support. That > > said, that code is no longer supported by OpenSSL so it may not be a > > concern. > > > > Thoughts on the updated plan. Suggestions for a different approach? > > I like what you have above, especially the decision to go to 2.0 because > it will be such a big API change. I don't want people complaining that > we removed some obscure file-manipulation call we've had in there since > the beginning in a .1 release or something like that. > > I also agree with Rémy about Panama: being able to ditch tcnative would > be really great. It's a source of headaches and just "more code" most of > which is glue.
Also if OpenSSL does QUIC (they promised a high level API ...), then it will be possible to use it through Panama. > I'd be interested to know what has happened with the new, rapid pace of > JVM releases in terms of the TLS stack. Specifically, Jean-Frederic > determined a few years ago that the JDK wasn't using hardware > acceleration for the AES block cipher which was killing the performance > of a lot of the TLS stack, and so OpenSSL-based TLS would continue to be > a requirement for high-performance TLS with Tomcat. >From what I can tell OpenSSL is still significantly faster on the same commonly used cipher. There's more difference for the (more complex) handshake process (it's really much faster there). > I think that was around Java 8 or Java 9, but we have 10 more versions > to consider these days. If Java itself is out of that rut, I thin it > makes tcnative even *less* useful. I thikn it may be required in > environments where exotic components are used like HSMs, but for most > people I hope tcnative+OpenSSL won't be required for very much longer. Maybe we should only count LTS releases though (11, 17, 21). So basically, we should be able to drop tomcat-native as soon as we're willing to tell people they need Java 21 to use OpenSSL. So if that new tomcat-native 2.0 branch happens, then it gives a nice functional bridge for a few years towards what the Panama version will provide. Rémy > Jean-Frederic, are you able to re-test a modern JVM to see if hardware > acceleration is actually being used these days? > > -chris > > > On 23/05/2022 11:52, Mark Thomas wrote: > >> Hi all, > >> > >> A question on the users list about Tomcat Native, OpenSSL 3.0 FIPs > >> caused me to take a look at the current state of supported versions. > >> > >> The detail is here: > >> https://github.com/apache/tomcat-native/blob/main/native/srclib/VERSIONS > >> > >> The planned transition to Tomcat Native 1.3 never happened in April > >> 2021 so I'd like to propose the following: > >> > >> - Create a 1.2.x branch from current main > >> - main becomes 1.3.x > >> - 1.3.x is updated to require at least OpenSSL 1.1.1 > >> - 1.3.x is updated to require at least APR 1.6.3 > >> - Update 1.3.x to support OpenSSL 3.x in FIPS mode > >> - Update 10.1.x to require at least Tomcat Native 1.3.x > >> > >> 1.2.x releases will continue until we have a stable 1.3x release. > >> > >> Thoughts? > >> > >> Mark > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: dev-h...@tomcat.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
