On Mon, Jul 21, 2014 at 5:14 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote:
> Le 20/07/2014 23:11, Jeff MAURY a écrit : > > On Sat, Jul 19, 2014 at 6:25 PM, Emmanuel Lécharny <elecha...@gmail.com> > > wrote: > > > >> Le 19/07/2014 17:34, Jeff MAURY a écrit : > >>> 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. > >> > >> What I read from the spec (RFC 6101, par 5.5) : > >> "the client sends a client hello message to which the server must > >> respond with a server hello message, or else a fatal error will occur > >> and the connection will fail " suggest the opposite. > >> > > This is related to the initial handshake. What we are discussing is more > > rehandshake and the fact that the server has messages to sent to will > > precede the handshake messages. > > I am reading the TLS spec (RFC 5246) not the SSL one (will do it). > > If you look at the TLS spec, the chapter 7.1 says: > > > > The ChangeCipherSpec message is sent by both the client and the > > server to notify the receiving party that subsequent records will be > > protected under the newly negotiated CipherSpec and keys. Reception > > of this message causes the receiver to instruct the record layer to > > immediately copy the read pending state into the read current state. > > Immediately after sending this message, the sender MUST instruct the > > > > record layer to make the write pending state the write active state. > The SSL sepc says basically the same thing. > > However, that only means we shoudl switch to the new keys when the > handshake is done. It does not say anything about any pending message. > > I still think that once one peer has started an HandShake, whatever > pending message will be lost, because I don't think the SslEngine will > handle an incoming data not being part of the handshake protocol. > TLS 1.2 spec says (chapter 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 So, in my opinion, we may continue sending the old data using the old keys even after we received the re-handshake request. The only problem that I see is if the user submit messages before the initial handshake has been completed. As we decided to encrypt messages when they are submitted, we may not be able to encrypt because the handshake is not finished so the ssl engine has no key materials yet. Jeff -- 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
