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
