Java SSLSocketChannel/SSLSelector?

[Andi Mullaraj]

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
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190215/e55f7681/attachment.htm>