Hi, just wanted to add my 2 eurocent, don't know if it really makes sense in the discussed context.
In Vysper, a state machine is maintained which tracks the connection status between connected, started, authenticated, encrypted, etc. Depending on the connection state, Vysper will reject messages which are not applicable at this point in time. This is due to the fact that the XMPP spec is pretty strict in terms of specifying error conditions when a message comes in which is not allowed at this stage, requiring to shut down a connection when messages are out of order. The same is applicable to outgoing messages, to shield the user from doing stupid things. The general goal is to rigorously protect against attacks by undermining the normal handshake flow, which is hard enough anyway. I'd always opt for being as strict as possible. Bernd On Thu, Jul 17, 2014 at 7:33 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote: > Le 17/07/2014 18:01, Jeff MAURY a écrit : >> On Thu, Jul 17, 2014 at 5:53 PM, Emmanuel Lécharny <elecha...@gmail.com> >> 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 ? > > As usual : we keep the remining message in the queue. > > We can't know beforehand if the socket will contain the full buffer or > not : we have to wrote it first. > > Here, we have two issues : > - the message has been fully encrypted, we just have to write what we > can, and keep the encrypted message in the queue. When the socket will > be ready, we will write the remaining data (the buffer is a ByteBuffer, > it knows where it stopped). > - the message was too big to be encrypted in a single buffer. > > The real issue is the second use-case. I think we should continue the > encryption when the first buffer has been fully sent here, but we might > want to first encrypt the full message before trying to send it. >
