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