On 09/12/2020 13:36, Graham Leggett wrote: > On 01 Dec 2020, at 14:09, Mark Thomas <ma...@apache.org> wrote: > >>> I also object to the removal of OpenSSL code, for the same reason. >> >> It isn't being removed. The APR/Native library will be retained along >> with OpenSSL support for the NIO and NIO2. >> >> I expect the scope of the APR/Native library for Tomcat 10.1.x onwards >> will be reduced to just those native methods required to interact with >> OpenSSL which may mean removal of the APR dependency. If we can use >> OpenSSL without any native code of our own (e.g. via project Panama or >> similar) then better still. > > I don’t see the logic here. > > If the use of native code is a risk, then I expect to see use of openssl and > any other API brought in by Panama avoided for the same reason?
Risk vs reward. Using APR to perform the low-level I/O creates additional risk without little/no reward. Any performance benefits of using APR are offset against the associated performance costs of transitioning the JNI boundary. For HTTP the performance difference beteeen NIO, NIO2 and APR/Native was negligible. You could construct a test to prove any was marginally better than the others but the differences were tiny. The performance difference between OpenSSL and JSSE continues to be significant. The speed at which new features are available is also a factor. Java 8 has only just got TLS 1.3 support. Post handshake authentication is, as far as I am aware, still unsupported. The situation with ALPN was similar. Using native code is not without risks but the risks are smaller if we just wrap OpenSSL because the scope of the native code is narrower. For HTTPS, NIO/NIO2+OpenSSL offers similar performance to APR/Native+OpenSSL at a lower risk. For users for whom the risk of using Native code is acceptable, NIO/NIO2+OpenSSL offers the same benefits at lower risk compared to APR/Native+OpenSSL. >>> We are in the middle of a global pandemic. Our users do not have the >>> resources to suddenly divert to reengineering what is to them a perfectly >>> working system, to replace what exists with something else that just works >>> differently. >> >> Upgrading to Tomcat 10 already requires significant re-engineering work >> due to the java package change for all the specification APIs. >> >> Switching an HTTP or AJP connector from APR/Native to NIO or NIO2 with >> OpenSSL requires a change of three/four characters in one configuration >> file. We have deliberately made it very easy to switch between connectors. >> >> No-one is being forced to upgrade. > > Atlassian forced me to upgrade. Then complain to Atlassian. I'd be very interested to understand Atlassian's reasoning if they are prepared to share it. > This is the core of the problem - gone are the days when Tomcat was just a > simple server that people downloaded and used to make bespoke web services > and could write code any way they liked. Now Tomcat is part of other systems, > who in turn have other support horizons unrelated to this project. > > The AJP deprecation is a problem. For those unaware of what AJP did, AJP > allowed a proxy server and Tomcat to be “glued” together as it they were one > server, and not two discrete entities. The proxy configuration - that’s SSL, > authn and authz - was passed transparently across to Tomcat which behaved as > if Tomcat itself had performed the SSL, authn and authz. Sure, if you have a > bespoke web service and the budget you can make hack changes to compensate. > If your Tomcat is being provided by a vendor, or if you’re under financial > strain due a pandemic, then no - you have a sudden very unwelcome headache. > > The closest RFC compliant solution to this problem is JSON Web Tokens (JWT), > which allows data to be passed across both securely and in an RFC compliant > way over HTTP. Tomcat should have fixed this problem first, and then > deprecated AJP with the clear notice “use this alternative in future”. AJP is not deprecated. Tomcat has not deprecated support for AJP nor announced plans to deprecate support for AJP. Tomcat has not made feature parity with AJP a priority for the AJP alternatives because there are no plans to deprecate AJP. Deprecation of AJP was discussed back in 2018 but no decision was made. Reviewing those discussions the primary motivation for deprecation seemed to by the argument that AJP did not (and was not likely to) provide support for features like WebSocket and encryption. I can see the arguments for deprecating AJP now as I did then but the size of the user base and the lack of feature parity with the mod_jk alternatives for IIS (at least the last time I looked) means I think it is unlikely AJP will be deprecated any time soon. Even when we had the recent security issue with AJP (CVE-2020-1938) none of our communication around that issue indicated that AJP was even being considered for deprecation nor did it suggest users switched to a different protocol. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
