On Mon, Jul 21, 2014 at 3:32 PM, Emmanuel Lécharny <[email protected]> wrote:
> Le 21/07/2014 11:53, Jeff MAURY a écrit : > > On Mon, Jul 21, 2014 at 5:14 AM, Emmanuel Lécharny <[email protected]> > > wrote: > > > >> Le 20/07/2014 23:11, Jeff MAURY a écrit : > >> > >> 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 > > Good find !!! > > However, I wonder how the SslEngine will react in this case... Time for > some experimentation ! > The spec clearly specify that there is a current read and write key materials and a pending one. > > > > > > 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. > > Hmmm. That would mean the user does not wait for the handshake to > complete, which sounds like a pb. All in all, the client which initiate > a new HandShake is supposed to wait for this handshake to be completed, > before sending anything, right ? OTOH, what if the client has some > pending messages... > BTW, we don't have an event to signal the end of the handshake (which is what we need to think about) and even if we had one, we need to handle this case. > > > 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. > > Yes, but I thought we agreed on the fact that messages should only be > encrypted when we are writing them in teh socket, not before? > No, I revert it because it will not be in line with the re handshake case. And you agreed (July 19th 6:25PM): > 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 That, I agree. IMO, we should never encrypt before sending. -- 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
