There are workarounds for both problems: using SSL offloading and/or using our boot path patched JSSE for ALPN. Neither approach is optimal, however, especially as the interest in having connections secure within the data center continues to rise.
We have previously looked at JNI native integration with a library like OpenSSL, but it was simply too much work to integrate and maintain. Having a well-maintained SSL integration is important as ciphers do change and exploits are found, so it is vital that updates are available as soon as the base library is updated.
Luckily, all that hard work is now done by others and we are able to stand on the shoulders of taller giants! Google maintains BoringSSL as a fork of the OpenSSL project that is used in their Chrome and Android products, thus it is an excellent well maintained library with good security and performance. Google have also built on the work of the Netty project to develop Conscrypt as the Java library that maps the native BoringSSL API to be a compliant JSSE SecurityProvider.
So how do you implement Conscrypt in Jetty? It is actually quite easy: instantiate an instance of Conscrypt’s OpenSslProvider; add it as a provider in the JVM’s Security class; set “Conscrypt” as the provider name on Jetty’s SslContextFactory.
Using the Jetty distribution? Since Jetty-9.4.7, these steps can all be done by enabling the “conscrypt” module:
java -jar $JETTY_HOME/start.jar --add-to-start=conscrypt
The integration with ALPN required a bit more work and some collaboration with the Conscrypt team. This will be included in the 9.4.8 release of Jetty as part of the conscrypt module enabled above.
So far, we’ve had reports of almost a 10 times increase in throughput with Conscrypt! It also provides ALPN support on both Java 8 and Java 9 without the need to amend the boot path. Try it out!