+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 <[email protected]>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
