Hi, As part of a university project, Numa de Montmollin, a student interning @redhat, has worked on adapting to Tomcat some code I discovered inside the Netty project, which implements a SSL engine using OpenSSL.
Normally, this sort of thing is supposed to be done using JCE, as was attempted earlier by the Apache Juice project. However, JCE is very complex (which probably explains the failure of Juice), is difficult to use for the end user, and may not even yield optimal performance. The Netty folks instead smartly identified a spot in the JSSE API that could be hacked and (ab)used it (I am not certain this was intended, since the SPI API on SSLContext forces use of JCE instead). Effectively, this allows replacing the regular SSLEngine with an equivalent backed by OpenSSL, and it is rather simple to achieve once you know what to do. Early performance results show the NIO(2) connector with SSL being equivalent or maybe even slightly faster than the APR connector, with JSSE very far behind. With SSL being nearly mandatory in the new protocols, SSL performance becomes a very important factor. For speed testing of the prototype, I used my obligatory: ab -c 100 -n 100000 -k -Z "AES128-GCM-SHA256" https://127.0.0.1:8443/tomcat.gif Notes: - JSSE is very bad at GCM, it needs a JVM fix (OTOH, without it, it is still significantly slower). - The performance is better with direct buffers (where it matches APR for me) but it remains very acceptable without it if needed (for example for scatter/gather calls). There's no reason not to use direct buffers for the SecureNIO(2)Channel however. The forked Tomcat 8 has a ready to use demo config in its conf folder. The code is here: - Tomcat 8 fork: https://github.com/rmaucher/tomcat80-openssl - Native fork: https://github.com/rmaucher/tomcat-native-openssl Technically: - The Java code [except the JNI update obviously] is self contained since I added in trunk the SSLContext interface that is used as the main hook. - The native code is simply the vanilla native Netty code forked from tcnative. The student has no plan to make any further changes to it. - Trunk SSL config was unstable so this uses Tomcat 8. I've started porting it today (incl cleanup and package renaming), I expect I'll be done very quickly. - The configuration is a WIP. [with the trunk port, the SNI changes are taking care of a major item here, since they have both types of config] The hardest to merge by far is the native portion. The Netty fork has some fixes (apparently), feature additions (poller, NPN/ALPN, OSCP, from what I saw) in addition to the (many) new SSL methods needed for the SSL engine implementation. So there's a need for review on how and what to merge. Comments ? Thanks, Rémy
