On 18/05/2015 16:46, Rémy Maucherat wrote: > 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 ?
Very, very nice. On the native side, I'm all for taking as much as we can. No reason not to aim for something that the Netty folks can just use without having to patch locally. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
