On Thu, Jul 17, 2014 at 5:53 PM, Emmanuel Lécharny <[email protected]> wrote:
> 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. > OK, I agree but what is the resulting buffer cannot be written to the socket because it is too large ? > > 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. > +1 > > > 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. > OK > > 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... > Jeff > > 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
