Java SSLSocketChannel/SSLSelector?

[Andi Mullaraj]

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