Le 30/07/2014 23:26, Jeff MAURY a écrit : > Hello, > > after thinking about the messages ordering and rehandshaking, I agree that > we should encrypt just before sending.
Ahhhh.... > 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. True. I see no simple way to mitigate this issue, but expect that the client will not do a handshake when it is expecting some data from the server. > 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. Regarding this event, that would mean we are switching from a SSL connection to a Clear Text connection. I can see some use cases where it can happen. > Sending > an event allow the application to decide what to do, maybe we should also > have a flag to automatically close the connection. I agree with the second flag (SSL close event), not sure we should close the connection in this case.
