Le 21/07/2014 16:16, Jeff MAURY a écrit : > On Mon, Jul 21, 2014 at 3:32 PM, Emmanuel Lécharny <elecha...@gmail.com> > wrote: > >> Le 21/07/2014 11:53, Jeff MAURY a écrit : >>> 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 : >>>> >>>> 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. Yes, but I'm afraid the SslEngine does not make any difference between Handshake messages and non-handshake message. I'd like to be proven wrong though.
> >> >>> 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. Here, I guess you mean something like HandshakeDone in the IoHandler interface ? Not sure we need one. Do you have something else in mind ? > >>> 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. I agreed that we should encrypt at the last moment, when we are ready to write in the socket, not before.
