mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff MAURY <jeffma...@jeffmaury.com>
Subject Re: [MINA 3] SSL working session : a feedback
Date Tue, 07 May 2013 08:00:52 GMT
These flags are relative to the messages and not the session so I don't
think there is concurrent issue.

Jeff



On Tue, May 7, 2013 at 9:02 AM, Julien Vermillard <jvermillard@gmail.com>wrote:

> 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
>



-- 
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