Inline ... On Thu, Dec 1, 2022 at 7:24 AM Info <i...@betzel.net> wrote:
> Hi Simone, > > *What does this mean exactly? > OpenJDK8ServerALPNProcessor works fine in OSGi, so you should not need > to override anything. > * > > My current Jetty version OpenJDK8ServerALPNProcessor uses: > > * if (ALPN.class.getClassLoader()!=null)* > > But because my JDK version already contains the ALPN classes natively this > is needed: > > * alpnSelector** = > **SSLEngine**.**class**.**getMethod**(**"setHandshakeApplicationProtocolSelector"**, > **BiFunction**.**class**);* > > etc... So I copied that from a later Jetty implementation for now. > I've seen this scenario before, in a few different ways. 1. You are using an IBM based JVM. 2. You are using a non-official Jetty JAR (or building your own in the wrong way, or using a badly made uber jar). 3. You don't have the correct dependencies for your Runtime JVM. 4. You are not keeping up with the rapid pace of change on the public internet with SSL/TLS. *For #1 above*, all IBM JVMs are thoroughly brain-dead and fundamentally broken when it comes to SSL/TLS/Cipher Suites. Mainly because they refuse to actually use the standards and specs as intended and are leaning on the "backward compatibility" (to their old pre standards JVM implementation) excuse, making most standards compliant code not function on their JVMs. I don't recommend using IBM JVMs if you are using SSL/TLS. But if you do need to use them, you have tons of configuration to maintain and custom code to write to "bridge" the standard compliant operation of Jetty to the IBM "backwards" behaviors. *For #2 above*, this usually means the META-INF/services entries are missing and/or bad in your non-official Jetty JARs. *For #3 above*, you should be using the correct dependency for your JVM. If your runtime is Java 9+, then you would use the jetty-alpn-java-server. If your runtime is Java 8, then you would use the jetty-alpn-openjdk8-server. Your description of `*if (ALPN.class.getClassLoader()!=null)*` means you are using an ancient version of Jetty. As this was addressed in https://github.com/eclipse/jetty.project/issues/4443 a while ago (see commit 9bb92f81bd5206c3597889644a1dded127760e22 <https://github.com/eclipse/jetty.project/commit/9bb92f81bd5206c3597889644a1dded127760e22> ) Your "so i copied that from a later Jetty implementation" is troubling, you know that 90+ files were changed in Jetty to support ALPN in OpenJDK 8, right? There's been 1,600 commits between Jetty 9.4.27 (the last version of Jetty with your old solution) and Jetty 9.4.49 (the current version of 9.4.x) - 59 of which are directly in the ALPN tree. Upgrade your Jetty version properly, don't use this partial / incomplete solution. *For #4 above*, when working with SSL/TLS, you have to keep things up to date (this is not optional if you are on the public internet). This includes your JVM and your Jetty versions. Most people don't realize that your JVMs have an expiration date, specifically for users of SSL/TLS. (if you don't use SSL/TLS, then you can ignore the expiration date). - Joakim
_______________________________________________ jetty-users mailing list jetty-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-users
