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
