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 working session : a feedback
Date Tue, 07 May 2013 07:02:23 GMT
BTW those flags for negotiation state are locked ? since we can write
from another thread, it should no ?

On Mon, May 6, 2013 at 10:26 PM, Jeff MAURY <jeffmaury@jeffmaury.com> wrote:
> Agree with that. So we probably need a flag to tell do not encrypt that
> will also be used for handshake messages.
>
> Regards
> Jeff
>
>
> On Mon, May 6, 2013 at 5:31 PM, Emmanuel Lécharny <elecharny@gmail.com>wrote:
>
>> Jean-François,
>>
>> one interesting piece of information from the RFC :
>>
>> 7.1 :
>> ...
>>
>> "Note: If a rehandshake occurs while data is flowing on a connection,
>> the communicating parties may continue to send data using the old
>> CipherSpec. However, once the ChangeCipherSpec has been sent, the new
>> CipherSpec MUST be used. The first side to send the ChangeCipherSpec
>> does not know that the other side has finished computing the new keying
>> material (e.g., if it has to perform a time-consuming public key
>> operation). Thus, a small window of time, during which the recipient
>> must buffer the data, MAY exist. In practice, with modern machines this
>> interval is likely to be fairly short."
>>
>>
>> So it seems we should continue to use the old cipher until the new one
>> is in place.
>>
>> Still, we should accumulate user's message pending for write into a
>> queue, but not encrypt them until we are ready to send them. The bottom
>> of the queue should always contain an encrypted buffer containing a
>> block of SSL ready data, part of the message being written.
>>
>>   +---- This part has already been sent using cipher 1
>>   |
>>   |  +--- This part is currently being sent using cipher 1 when the
>> rehandshake is being processed
>>   |  |
>>   v  v
>> +~~~-------+ +----------+ +----------+ +----------+
>> | Message1 | | Message2 | | Message3 | | Message4 |
>> +~~~-------+ +----------+ +----------+ +----------+
>>     :   :
>>     :   :
>>     +---+
>>     |SSX| encrypted part of message1 partially sent (SS) and not sent (X)
>>     +---+
>>
>> In this diagram, the message1 is at the bottom of the queue, not
>> encrypted. We have already sent one block of 16Kb (a TLS data block) and
>> we are trying to send a new block, but were only able to send 2 third of
>> it, waiting for the socket to be ready to accept the last third.
>>
>> In this case, we don't re-encrypt the encypted part, as the remote peer
>> is already expecting some more data (BUFFER_UNDERFLOW) as the TLS data
>> packet has not been completely received.
>>
>> The remaining part of message1 though will be encypted using cipher2.
>>
>> At least, this is how I interpret the specification.
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
>
>
> --
> 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
View raw message