No, I don't agree with that because the spec says that the new key materials should be set current only when the change cipher spec message is received from the server. So I think we can continue sending messages encrypted with the old key if the handshake messages are after in the queue. The problem is that if we encrypt before sending it's likely that we will encrypt with the new key if the handshake message has been read processed by the ssl engine
Jeff — Sent from Mailbox for iPhone On Sat, Jul 19, 2014 at 5:19 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Some mor ethoughts, after I spent a couple of hours in Rescorla SSL's > book... > One of the critical point is what to do when we have pending messages to > write to a remote peer, which has initiated a (re-)handshake. > My initial take was that we should finish to send the current message to > teh remote peer before honoring the handshake request. But it does not > make a lot of sense : if the remote peer has already initiated a > (re-)handshake, it has also already set a SSLEngine on its side (or > whatever mechanism), and it will *not* excpect to receive anything but a > serverHello, and if it does not receives it, then it will consider that > is an error. > In any case, the client should probably not issue a (re-)handsake if it > is waiting for more data, but this is not the server to decide the > client is wrong (and we can imagine some protocols where the client is > not wrong, the server pushing some data without expecting the client to > wait for them). So I guess that if a message is waiting to be written > when some handshake is requested, then this message should be discarded > (with a error being generated) if it's partially sent, or postponed and > encrypted with the new negotiated keys (or not encrypted if the client > just stop teh SSL session. > Does it make sense ?
