users@grizzly.java.net

SSLEngine buffer underflows are not handled correctly in Grizzly

From: Bo Li <b.li_at_sun.com>
Date: Fri, 13 Nov 2009 11:16:55 -0600

I was just wondering if there are any updates on this issue? Let me know
if you need any help reproducing it. I can also attempt to write a fix
if needed.

Thanks again
Bo


With the latest snapshot of Grizzly 2, SSL connections hang when the
entire SSL packet is not read completely into one buffer. Here is what's
going on from my understanding:

1. TCPNIOStreamReader reads an incomplete SSL packet and set it as the
current buffer.
2. SSLStreamReader tries to unwrap the buffer's contents but get buffer
underflow. Returns false to appendBuffer.
3. TCPNIOStreamReader reads the rest of the SSL packet into another
buffer and appends it to the dataRecords list.
4. SSLStreamReader tries to unwrap the first buffer's contents again and
get buffer underflow. Returns false to appendBuffer.
5. Connection stuck with multiple encrypted buffers stored in
TCPNIOStreamReader's dataRecords.

The problem is that the read buffer is trimmed down to the size of the
read and subsequent reads are stored in different buffers. This makes
setting the buffer size to the SSLSession's packet buffer size useless.
SSLEngine expects one complete SSL packet in the net buffer. Since
SSLStreamReader doesn't append all the different buffers into one big
one before unwrapping, SSLEngine doesn't make any progress.

Let me know you have any questions with reproducing and/or understanding
the issue. This is currently a blocking issue for us.

Thanks again

Bo
OpenDS Core Developer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
For additional commands, e-mail: users-help_at_grizzly.dev.java.net