mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julien Vermillard <jvermill...@gmail.com>
Subject Re: [MINA 3] SSL and fragmentation
Date Fri, 03 May 2013 19:34:35 GMT
On extending java.nio.ByteBuffer : it's not doable because the constructor
is private :(

On Fri, May 3, 2013 at 3:40 PM, Jeff MAURY <jeffmaury@jeffmaury.com> wrote:

> +1
>
> I think we shall rewrite the code and let be driven by the underlying
> SSLengine status.
> Now, if after processing there are still remaining data in the input
> buffer, we must keep it until the next buffer is received.
> In order to preserve performances, as we need to assemble the input buffer
> with the rest of the previous input buffer, I had the idea of having a
> CompositeReadOnlyByteBuffer that extends ByteBuffer and that will be
> composed of the two buffers. This will prevent to perform costly copies
> while allowing the SSLEngine to see the whole data.
> Any thoughts ?
>
> Jeff
>
>
> On Fri, May 3, 2013 at 3:19 PM, Emmanuel L├ęcharny <elecharny@symas.com
> >wrote:
>
> > Hi guys,
> >
> > the way we handle incomming SSL data on the server will not work if the
> > data are fragmented.
> >
> > Let's say we are receiving some Handshake data. This is typically a few
> > hundreds of bytes, that usually comes in one block. In this case, we are
> > all good. But if those data aren't read in one block, then we are dead.
> >
> > I have simulated such a fragmentation by sending a ClientHello block of
> > data in three parts : as soon as the SslEngine if given the second block
> > of data, it throws an exception :
> > 2013-05-03 15:07:15,546 ERROR [SelectorWorker Server-I/O-1]
> > tcp.NioTcpSession (NioTcpSession.java:330) - Exception while reading :
> >  javax.net.ssl.SSLException: Unsupported record version Unknown-0.0
> >     at
> >
> >
> sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:116)
> >     at
> sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:845)
> >     at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:758)
> >     at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
> >     at org.apache.mina.session.SslHelper.unwrap(SslHelper.java:190)
> >
> >
> > This is plain normal : when we read the first block of data, we unwrap
> > it, and the SslEngine resturn with a BUFFER_UNDERFLOW status (expected).
> > Now, we return back to the main loop, and we *clear* the reaBuffer. We
> > then lose the first bytes we have read, parts that the SslEngine is
> > expecting to have the next time we call it.
> >
> > There is one way to avoid such a problem : we just have to compact the
> > buffer instead of clearing it.
> >
> > Now, regarding the SSL code, it's really messy atm. The fact that we
> > separate the handshake from the normal processing of data is wrong. When
> > we do an unwrap, it will initiate a handshake if needed. The fact is we
> > have to review the full code and rewrite it...
> >
> > I'm currently doing some experiments here, but I would be please to
> > share ideas, suggestion, proposals from any of you...
> >
>
>
>
> --
> Jeff MAURY
>
>
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com
> http://www.twitter.com/jeffmaury
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message