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
