Hello, after thinking about the messages ordering and rehandshaking, I agree that we should encrypt just before sending. The only problematic case that I can see is if the send queue is empty and the application submit a message when the last client handshake message is received : if both runs concurrently, it will be possible that the message will be encrypted using the new key materials but the changeCipherSpec will be sent after. I agree that the window is small. Regarding the event, I think we need two events: one for signaling the end of the handshake, another one when the close alert is received as the spec does not mandate the underlying transport connection to be closed. Sending an event allow the application to decide what to do, maybe we should also have a flag to automatically close the connection.
Jeff On Wed, Jul 23, 2014 at 11:58 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Le 23/07/2014 10:56, Jeff MAURY a écrit : > > On Mon, Jul 21, 2014 at 5:25 PM, Emmanuel Lécharny <elecha...@gmail.com> > > wrote: > > > >> 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. > >> > > According to the SSLEngine Javadoc, it does support renegiotiation: > > > > Rehandshaking - Either side may request a renegotiation of the session at > > any time during the Application Data phase. New handshaking data can be > > intermixed among the application data. Before starting the rehandshake > > phase, the application may reset the SSL/TLS communication parameters > such > > as the list of enabled ciphersuites and whether to use client > > authentication, but can not change between client/server modes. As > before, > > once handshaking has begun, any new SSLEngine configuration settings will > > not be used until the next handshake. > > Ok. I hope it works this way. In any case, it's just a matter of being > aware f this potential problem, and have a dedicated test for it. > > > > > > > >> > >>>>> 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. > >> > > It will allow the user application to know when messages sending can > start. > > Seems a reasonnable feature. +1 > > > > >>>>> 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. > >> > > We are not on the same position in that case, I would favor encrypting > when > > messages are submitted. > > You mean when the message is pushed into the send queue ? IMO, that > would cause more trouble than encrypting the message using the latest > known cipher, ie at the very last moment (when we are pushing the > message into the socket for the first time). > > > Can we start a separate thread on this specific question ? Or even > better, a JIRA. > > I'd like to hear from other opinion on this specific question too. > > Thanks ! > -- 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
