Hi java-core community, I have been directed to this channel to discuss matters related to Java performant ssl communications. Maybe this is a topic that has been discussed in the past, in which case I would appreciate if someone pointed me to that particular topic.
Back in 2002 I personally applauded the java.nio.channels (jdk1.4) package, realizing that there was no way to port this to the secure communications, due to lack of a comparable implementation for SSL. But I thought it was going to just be matter of time. A couple of years ago I had to go back search for it, and was kind of surprised to find the following in http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG : --- begin quote --- Newcomers to the API may wonder "Why not just have an SSLSocketChannel which extends java.nio.channels.SocketChannel?" There are two main reasons: 1. There were a lot of very difficult questions about what a SSLSocketChannel should be, including its class hierarchy and how it should interoperate with Selectors and other types of SocketChannels. Each proposal brought up more questions than answers. It was noted that any new API abstraction extended to work with SSL/TLS would require the same significant analysis and could result in large and complex APIs. 2. Any JSSE implementation of a new API would be free to choose the "best" I/O & compute strategy, but hiding any of these details is inappropriate for those applications needing full control. Any specific implementation would be inappropriate for some application segment. --- end quote --- It has been a while since this was stated, and I would really like to revisit it. I personally believe that the question #1 has a quite natural answer, while #2 should not really be a concern if we adhere to the spi model where users can bring their own implementation if needed. I know because I have also implemented it (but would like to discuss that in a later stage, if it comes to it). The benefit of such implementation would be immense. Imagine many Java services written with nio and which struggle to move to SSL due to the great complexity of using SSLEngine (zookeeper service to name one), while all they would need to do (if SSLSocketChannels were available) is to instantiate an instance of SSLSocketChannel/SSLSelector when the security is required and the rest would stay the same (as in case of plain communication using SocketChannel/Selector). Another important use case is the advent of IOT, where millions of devices, with relatively low throughput would want to protect their communication via SSL. The ways I have seen the community deal with this are mainly: 1. Go through the pain of learning SSLEngine (and hope to get it right) 2. Build their services around tested libraries (like Jetty, which handle the SSL offload but don't resurface it in SocketChannel/Selector paradigm, that also come with their huge set of dependencies, bringing in unavoidable version collisions) 3. Use proxies (nginx, ha) to deal with the high number of SSL connections and divide the load by scaling horizontally in the back end (making for a harder deployment model) We can make this a lot easier! Any feedback is greatly appreciated, Best, Andi Mullaraj
