Le 03/07/2014 00:42, Jeff MAURY a écrit : > Hello, > > I have spent some times reviewing the SSL code in order to add support > client handshake start. > I have seen several problems that I'd like to share: > > - messages sent are encrypted when they are submitted: I see two > problems with that: if a message is submitted before the handshake is > completed, then behavior is probably error. If a message is submitted so > queued but handshake happened between the data are sent to the socket, then > it's likely that remote won't be able to decode it.
How possibly ? Until the handshake is completed, you don't have the key to encrypt anything... The way it works (or the way it should work) is that as soon as you switch to SSL mode, then a handshake is done. That should block the sending of any message until the handshake is done. One potential pb we may have here is that swicthing from a normal state to SSL might be done while we do have some pending messages, but the key here is that those messages must be sent before we switch. > - Regarding the handshake, it may lead to data sent. In our > implementation, it queue another message to be sent which will not be > encrypted because the state is linked to the handshake but this means if > the application submits a message to send, it will not be encrypted as > well. Not sure I get it... > > The changes I propose are the following: > > - encryption performed only when data is to be written to the socket That what the spirit of the changes in SSL handling in MINA 3, compared to MINA 2. MINA 2 inject the SSL filter in the middle of the chain, making it extremely complex to deal with pênding messages and such. > - messages are stored with a flag to tell if they have been already > encrypted IMO, messages don"t need to be flagged. They are either encrypted, or they aren't, but in any case, we should send all the encrypted messages to the remote peer before we switch off the SSL mode, or we should send all teh unencrypted messages before we set up teh SSL mode. By all means, it's really liek a global switch which should hold any new messages until teh handshake is completed. > - messages generated as part of the handshake should probably queued at > the top of the queue instead of the tail for application messages. Not sure. As teh handshake will start by a CLIENT_HELLO message, until this message is sent, all the pending messages in teh queue must have been sent. That means we should not accept any other messages in teh queue until the end of teh handshake is reached. This is the real key : how to forbod the application to push messages in teh queue, as we will have to push some SSL Handshake messages in this queue ?
