Open isaacrivriv opened 1 year ago
The order of preference for Netty's SSL implementations according to the implementation here
After discussing this with the team, we need to keep the same behavior as our current implementation in Liberty. This means that possibly we need to expand on Netty's ALPN negotiator and add our already established implementations of ALPN on Liberty on top of Netty and test to ensure behavior stays the same.
The different ALPN implementations were added due to missing ALPN functionality in the various JDKs as discussed here
As of today it seems like all the major JDKs have added/back ported ALPN functionality to Java 8
For a start we should provide basic JDK support for ALPN and then discuss on the other implementations.
For HTTP2 encrypted traffic (h2), ALPN is required. In Netty we are able to use ALPN through OpenSSL (requires to be configured) or through the JDK see here. As stated in the Netty page, not all JDKs have ALPN only starting from a release in Java 8.
In Open Liberty for h2 traffic we use various implementations of ALPN with order of preference as seen here.
Netty has it's own set of implementations of ALPN and with an order of preference as well as seen here which seems to be consumed creating a JDKSSLContext here. Perhaps we could expand on these classes in our Netty TLS bundle and build similar implementations but with Open Liberty's implementations.
We need to discuss an approach for this.