Java SSLSocketChannel/SSLSelector?

Fri Feb 15 12:56:00 UTC 2019

Then your selector can only be used for SSL things.  What if someone
decides to take the exact same approach to solve some other
higher-OSI-layer protocol decoding?  Now you have to choose which kind
of protocol you want your selector to support.  Note that with a plain
selector and plain sockets, you *need* a thread to support the event
loop anyway, I mean it has to run somewhere.  And with SSL, you also
need an extra thread or thread pool to handle SSL authentication
tasks, no matter whether you make a subclass of Selector.

On Fri, Feb 15, 2019 at 2:35 AM Andi Mullaraj <andimullaraj at gmail.com> wrote:
>
> Hi Dean,
>
> Thanks for sharing your experience. I took a look at your links and the model and implementation seems quite distant from the classic Selector/SelectableChannel though. You seem to allocate a thread per each Selector (which I agree is too much of a cost to pay), then fire actively [listener.selectorFired()] from that thread towards a SelectorListener ...
>
> We can come back to implementation details later, but first I would like to ask: any reason we cannot have an SSLSelector which extends the java.nio.channels.Selector, an SSLSocketChannel extending a java.nio.channels.SocketChannel, and so on? I believe we can, and in this doc https://github.com/rouplex/rouplex-niossl/blob/master/README.md I have provided the set of base classes that do just that. Since this is a dev group I am sharing a code snippet from the doc:
>
> As an example, an existing application which is using SocketChannel with a Selector for their communications, would be turned into a secure one, by simply replacing:
>
> Selector selector = Selector.open();
> SocketChannel socketChannel = SocketChannel.open();
> socketChannel.register(selector, SelectionKey.OP_READ);
>
> while(true) {
>     selector.select();
>     for (SocketChannel sc : selector.selectedKeys() {
>         sc.read(...)
>     }
> }
>
> with:
>
> Selector selector = SSLSelector.open(); // notice the SSL
> SocketChannel socketChannel = SSLSocketChannel.open();  // notice the SSL
> socketChannel.register(selector, SelectionKey.OP_READ);
>
> while(true) {
>     selector.select();
>     for (SocketChannel sc : selector.selectedKeys() {
>         sc.read(...)
>     }
> }
>
> How much cooler and easier than that can it get redressing your existing service using (performant) plain communications with (performant) secure ones? Or create a new (and secure) one using the exact knowledge you already have and never having to think SSLEngine again?
>
> As I have already mentioned I have worked on such implementation but would like to first discuss with the group the merits and possible problems/shortcomings of adopting the inheritance model from the plain counterparts.
>
> Thanks in advance,
> --Andi
>
>
> On Wed, Feb 13, 2019 at 8:22 AM Dean Hiller <dhiller at twitter.com> wrote:
>>
>> I would highly suggest implementing your own for a much better understanding.
>>
>> I did implement something like what you want and in so doing realized I like their decision.  ie. See the heirarchy here
>> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels
>>
>> The TCPChannel could be SSL or not SSL as there are two implementations.
>>
>> If you do want an implementation that does what you want though, this library does exactly that
>> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2
>>
>> which is used in the webpieces webserver
>> https://github.com/deanhiller/webpieces
>>
>> That nio library is standalone even though it is in the webpieces repo.  I mean, every component in webpieces is another stand-alone piece.
>>
>> The downside is the library owns a thread which typical java libraries avoid.  ie. it has to have a thread to poll the selector and read from all the sockets to be fed to the thread pools, etc.  I think that is the main reason they decided not to have this type of library.  They prefer not to be running threads(which I agree, the jdk shouldn't).
>>
>> later,
>> Dean
>>
>>
>>
>>
>> On Tue, Feb 12, 2019 at 7:54 PM Sean Mullan <sean.mullan at oracle.com> wrote:
>>>
>>> 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
>>> >

-- 
- DML