Le 17/07/2014 23:34, Bernd Fondermann a écrit : > 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.
The SSLEngine itself uses a state-machine to handle the various states. But from the SSL protocol point of view, it's quite simple, we have three different cases : - SSL is not activated - SSL is being negociated (and we have various internal states, but nothing can be exchanged but handshake messages during this phase) - SSL is activated The difficulty is to manage the transitions between those three states, and as we have two sides (the server and the client), which aren't necessarily in sync (we don't always know when the client will send a handshake request, or some data : it really depends on the procotol being implemented), we can't impose anything.
