Java SSLSocketChannel/SSLSelector?

[Sean Mullan]

Hi Andi,

TLS/JSSE topics are best discussed on the security-dev alias, so I am 
copying that list for more discussion and -bcc-ing core-libs-dev.

--Sean

On 2/11/19 3:29 PM, Andi Mullaraj wrote:
> 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
>