Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-13924

HTTP2 is not working with Oracle JDK8 u261

    XMLWordPrintable

    Details

    • Steps to Reproduce:
      Hide

      Info about JDK used:

      $ /home/jstourac/jdks/jdk1.8.0_261/bin/java -version
      java version "1.8.0_261"
      Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
      Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)
      

      Legacy Security Realm

      1. unzip the WildFly
      2. start the server with proper JDK
        JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh
        
      3. wait till server boots up and perform an HTTP request (note that curl with HTTP2 support has to be used, otherwise use different client)
        curl -k https://localhost:8443 -vvv >/dev/null
        
      4. see that HTTP/1.1 is used only; there is also this message in the output
        • ALPN, server did not agree to a protocol

      Now workaround:

      1. unzip the WildFly
      2. start the server with proper JDK and property from UNDERTOW-1726
        JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh -Dio.undertow.protocols.alpn.jdk8
        
      3. wait till server boots up and perform an HTTP request
        curl -k https://localhost:8443 -vvv >/dev/null
        
      4. see that HTTP/2 is used successfully now

      Unwrapped Elytron Configuration

      This step needs to be run AFTER the first step so the default self signed certificate is pre-generated.

      Execute the following CLI commands to switch to an Elytron SSLContext:

      /subsystem=elytron/key-store=test:add(relative-to=jboss.server.config.dir, path=application.keystore, credential-reference={clear-text=password})
      /subsystem=elytron/key-manager=test:add(key-store=test, credential-reference={clear-text=password})
      /subsystem=elytron/server-ssl-context=test:add(key-manager=test)
      
      batch
      /subsystem=undertow/server=default-server/https-listener=https:undefine-attribute(name=security-realm)
      /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context, value=test)
      run-batch
      

      The same curl command can be used to test the establishment of a HTTPS connection.

      Using the system property -Dio.undertow.protocols.alpn.jdk8 again restores the ability to use ALPN.

      Wrapped Elytron Configuration

      It was always preferred that the Elytron subsystem would wrap the SSLContext to prevent against unintended modification but we had to drop to unwrapping to support the JDK 8 hack needed for ALPN.

      This third test should be executed after the previous test as it is a continuation of the configuration.

      Execute the following CLI to ensure the SSLContext is wrapped:

      /subsystem=elytron/server-ssl-context=test:write-attribute(name=wrap, value=true)
      

      If the server is restarted with or without the system property ALPN is not available.

      Show
      Info about JDK used: $ /home/jstourac/jdks/jdk1.8.0_261/bin/java -version java version "1.8.0_261" Java(TM) SE Runtime Environment (build 1.8.0_261-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode) Legacy Security Realm unzip the WildFly start the server with proper JDK JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh wait till server boots up and perform an HTTP request (note that curl with HTTP2 support has to be used, otherwise use different client) curl -k https: //localhost:8443 -vvv >/dev/ null see that HTTP/1.1 is used only; there is also this message in the output ALPN, server did not agree to a protocol Now workaround: unzip the WildFly start the server with proper JDK and property from UNDERTOW-1726 JAVA_HOME=/home/jstourac/jdks/jdk1.8.0_261 ./wildfly-20.0.0.Final/bin/standalone.sh -Dio.undertow.protocols.alpn.jdk8 wait till server boots up and perform an HTTP request curl -k https: //localhost:8443 -vvv >/dev/ null see that HTTP/2 is used successfully now Unwrapped Elytron Configuration This step needs to be run AFTER the first step so the default self signed certificate is pre-generated. Execute the following CLI commands to switch to an Elytron SSLContext: /subsystem=elytron/key-store=test:add(relative-to=jboss.server.config.dir, path=application.keystore, credential-reference={clear-text=password}) /subsystem=elytron/key-manager=test:add(key-store=test, credential-reference={clear-text=password}) /subsystem=elytron/server-ssl-context=test:add(key-manager=test) batch /subsystem=undertow/server= default -server/https-listener=https:undefine-attribute(name=security-realm) /subsystem=undertow/server= default -server/https-listener=https:write-attribute(name=ssl-context, value=test) run-batch The same curl command can be used to test the establishment of a HTTPS connection. Using the system property -Dio.undertow.protocols.alpn.jdk8 again restores the ability to use ALPN. Wrapped Elytron Configuration It was always preferred that the Elytron subsystem would wrap the SSLContext to prevent against unintended modification but we had to drop to unwrapping to support the JDK 8 hack needed for ALPN. This third test should be executed after the previous test as it is a continuation of the configuration. Execute the following CLI to ensure the SSLContext is wrapped: /subsystem=elytron/server-ssl-context=test:write-attribute(name=wrap, value= true ) If the server is restarted with or without the system property ALPN is not available.
    • [QE] How to address?:
      ---
    • [QE] Why QE missed?:
      ---

      Description

      There seems to be some problem with HTTP2 support with new Oracle JDK8 u261 and WildFly since 20.0.0.Final version. When request against server is executed, then HTTP2 is not established and communication remains via HTTP/1.1.

      There is no such issue when I use WildFly 19.0.0.Final. Also, if I switch back to an older Oracle JDK8 u241, there is no such issue even with newer WildFly versions.

      This all seems to be tied with backport of ALPN support into the Oracle JDK8 recently and also work in following issue UNDERTOW-1726.

      There seems to be a workaround available - to define '-Dio.undertow.protocols.alpn.jdk8' during the server startup. With this property configured, the issue seems to disappear (as such, blocker priority of this may be discussed).

      What is the issue here:

      This is a change in default behavior of the server (HTTP2 not working with Oracle JDK8u261+ since WildFly 20.0.0.Final). We should try to resolve this without default behavior change if possible. Only in case there is really no other solution, we need to document such thing.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              flaviarnn Flavia Rainone
              Reporter:
              jstourac@redhat.com Jan Stourac
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: