Le 17/07/2014 17:15, Jeff MAURY a écrit : > Hello, > > back to work, I have the following thoughts: > > - encrypting just before we write to the socket may lead to other > problems: if the resulting message is greater than the send buffer, then we > would need to wait for the rest of the buffer. This is already handled by the SslEngine. We have to provide a wide enough buffer to the sslEngine.wrap() method.
OTOH, if your concern is that we should defer the encr > If between, we receive an > handshake, we may risk the data to be sent with wrong key materials Not sure, because we haven't yet processed the handshake. Now, if the client starts a new handshake (re-handshake), I'm not sure it will accept any incoming message which is not part of the handshake it started. Here, I would say it's more a protocol pb than an implementation pb for us. > but if > the handshake acknowledgment is queued after those application messages, > this may be ok, we should look at what the spec says about this case. So > maybe we should keep encryption performed when the message is queued, > assumed we handle the case properly if handshake is not yet finished. I'll check my SSL book :-) > - I don't see the purpose of the timestamp, do you want to > timestamp/version the handshake acks to detect a message encrypted by key > materials 1 when it was submitted will be sent as key materials 2 has been > activated ? I think if we simply queue messages,we don't need it. Forget about the timestamp. I think I was wrong when I was assuming that a message should be encrypted using an old key when a re-handshake has occured. What is important here is to send encrypted messages that the remote peer can decrypt. This is also why I think we should really encrypt when we write into the socket. BTW, I'm quite sure that one can't start a re-handshake when teh SSL engine is processing some incoming messages, so when we have started to send an encrypted message, we should be safe. The only critical part is when the server starts to write an encrypted message while the remote peer starts a re-handshake at the very same time. The spec should say something about it... Thanks !
