On 18.07.14 00:35, Emmanuel Lécharny wrote:
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.
ok, I see. So my post didn't really add anything substantial to the
discussion, I guess. Sorry for the noise.
Bernd
