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