Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-17893

TLSv1.3 via wildfly-openssl discrepancy between JBoss EAP and WildFly

    XMLWordPrintable

Details

    • Bug
    • Resolution: Obsolete
    • Minor
    • None
    • 7.2.3.GA, 7.2.4.GA, 7.3.0.CD17
    • Build System, Security, Undertow
    • None
    • Hide
      1. start the server with JDK11+ 
        $ JAVA_HOME=~/jdks/openjdk-11 ./jboss-eap-7.3/bin/standalone.sh
      2. configure OpenSSL security provider (OpenSSL libs in version 1.1.1+) and perform server reload 
        $ ./jboss-eap-7.3/bin/jboss-cli.sh -c
/core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol,value=openssl.TLS)
reload
      3. perform HTTP request against server and see what TLS and HTTP versions are used: 
        $ curl -k -vvv https://127.0.0.1:8443 > /dev/null
      Show
      start the server with JDK11+ $ JAVA_HOME=~/jdks/openjdk-11 ./jboss-eap-7.3/bin/standalone.sh configure OpenSSL security provider (OpenSSL libs in version 1.1.1+) and perform server reload $ ./jboss-eap-7.3/bin/jboss-cli.sh -c /core-service=management/security-realm=ApplicationRealm/server-identity=ssl:write-attribute(name=protocol,value=openssl.TLS) reload perform HTTP request against server and see what TLS and HTTP versions are used: $ curl -k -vvv https: //127.0.0.1:8443 > /dev/ null

    Description

      There is some discrepancy between JBoss EAP vs WildFly release when legacy security and OpenSSL security provider is used.

      With JBoss EAP 7.3.0.CD18-CR1 running with JDK11+, it is possible to utilize TLSv1.3 with OpenSSL 1.1.1d but with same configuration and prerequisities, it is not possible to do the very same with WildFly 18 - TLSv1.2 is used in this case instead. When I manually copy wildfly-openssl native library from JBoss EAP into WildFly:

      $ cp jboss-eap-7.3/modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so wildfly-18.0.0.Final/modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so

      (note that only libwfssl.so native library part is required for this, wildfly-openssl*.jar artifact does not have to be updated) then I can see that TLSv1.3 is successfully utilized now too. It looks like the wildfly-openssl native library part is built differently for JBoss EAP vs WildFly releases.

      What is correct behavior is a little bit questionable to me now (maybe both with regards to their particular releases?). Following should be mentioned here:

      1. There's officially no support for TLSv1.3 in JBoss EAP provided yet. It is supposed to be incorporated by this RFE EAP7-1022, currently targeted at JBoss EAP7.4.0.GA. Although, even when this RFE is delivered, it is aimed against Elytron security subsystem only with no plan to further feature enhancements for legacy security subsystem.
      2. There are only TLSv1, TLSv1.1 and TLSv1.2 enabled via 'enabled-protocols' attribute in legacy security by default. As such, we would not ran into this issue if there is not following issue present too, see WFCORE-4737 for more info.

      Maybe all that is required here is not a fix but just a clarification. Is the different behavior I see between the JBoss EAP and WildFly correct and expected? I believe that since WFCORE-4737 is fixed, this discrepancy is gonna be concealed again, although we may run into it later on again.

      Note that there seems to be also some problem to use HTTP2 in case TLSv1.3 is utlized with this configuration, although, it is not scope of this issue. I'm not gonna report that problem now since TLSv1.3 is not officially supported yet.

      Attachments

        Issue Links

          relates to

          Bug - A problem that impairs or prevents the functions of the product. WFCORE-4737 CVE-2019-14887 The 'enabled-protocols' value in legacy security is not respected if OpenSSL security provider is in use

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              Unassigned Unassigned
              jstourac@redhat.com Jan Stourac
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: