mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: [MINA 3] SSL and fragmentation
Date Fri, 03 May 2013 15:58:24 GMT
Le 5/3/13 4:45 PM, Jeff MAURY a écrit :
> On Fri, May 3, 2013 at 3:47 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote:
>
>> Le 5/3/13 3:40 PM, Jeff MAURY a écrit :
>>> +1
>>>
>>> I think we shall rewrite the code and let be driven by the underlying
>>> SSLengine status.
>> Absolutely. I have created a branch to play a bit with SSL.
>>> Now, if after processing there are still remaining data in the input
>>> buffer, we must keep it until the next buffer is received.
>> Thus the compact().
>>
>> The pb is for the normal calls (ie, not SSL- as the buffer can be
>> propagated up to the user. In this case, if we compact the buffer, we
>> may get some weaird side effect if the user has done some weird things
>> wih the buffer.
>>
> Why do we need to take care of non SSL configuration in this SSL discussion
> ?

Sorry, I was unclear. I meant when we have already processed the
Handshake. The unwrapped buffer will be probagated to the user, and can
potentially be modified (even if it's a mistake).

Not sure this is a big issue atm...
>
>
>>> 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 ?
>> That's an option.
>>
>> However, internally, the SslEngine does copy the ByteBuffer if it's not
>> a Direct buffer. So I'm not sure we can spare any CPU time by
>> concatenating the received ByteBuffer into a composite structure.
>>
> I think so as I suspect the SSLEngine to be message oriented so when an
> input buffer is given, then the SLL engine will read the first bytes to
> decode the length and if not enough data is present, it will throw a
> BufferUnderflow so only the first bytes of the input buffer will be read
> and taht's why we need to concatenate.

This is most certainly what the SSLEngine does. A SSL message typically
starts with a heade :

b[0] : ContentType {0x14:ChangeCipherSpec, 0x15:Alert, 0x16:Handshake,
0x17:ApplicationData}
b[1-2] : Version {3.0 : SSL 3.0, 3.1 : TLS 1.0, 3.2 : TLS 1.1, 3.3 : TLS
1.2}
b[3-4] : length <= 2^14 (16Kb)

So if it gets at least 5 bytes, the SslEngine can know how many bytes to
expect.
>
>> I mean, if we pass a DirectBuffer to the SslEngine, it will be faster.
>> If this DirectBuffer does not contain enough data to produce an
>> unwrapped buffer, the we will have to pass a new DirectBuffer containing
>> the previous data (copied from the previous DirectBuffer) plus the newly
>> read data. In any case, we have some copy...
>>
> I don't think so.
If we reuse the readBuffer (which is allocated once per session),
without clearing it between reads, and if it's a DirectBuffer, then I
think there is no copy done.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


Mime
View raw message