Java SSLSocketChannel/SSLSelector?

Sat Feb 16 22:18:19 UTC 2019

Hi David,

Thanks for following up. Addressing your questions and statements

1. Then your selector can only be used for SSL things.

The SSLSelector I am proposing may select on (plain)
SocketChannels/ServerSocketChannels, (secure)
SSLSocketChannels/SSLServerSocketChannels, and any mixture of them.

2. 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.

They create their own selector. I have hard time imagining one selector
implementation being able to support various protocols at once. In the
current discussion (and if one day this or a similar implementation makes
it into jdk), the selector provider will know how to create (plain)
SocketChannels as well as (secure) SSLSocketChannels.

3. 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.

I don't have enough knowledge here, but I am thinking it will depend on the
OS ... if the OS provides similar hooks, then I'd say no other threads are
needed -- the thread selecting would be entering a wait() until some
notifier wakes it up ... not vital to the SSL part though.

4. 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.

True. Resisting the temptation to get into implementation details, I would
say it is the SSLSocketChannel that needs the thread pool (since the calls
to select() should not deal with any crypto etc). In that case the user can
bring its own thread pool (or executor), or use a default one shared by all
channels of that selector provider, depending on their needs.

Best,
--Andi

On Fri, Feb 15, 2019 at 4:56 AM David Lloyd <david.lloyd at redhat.com> wrote:

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