Yannick Koehler wrote:
> This make me suspect that our function that checks in which context a
> packet come from is broken.
< Which side has the responsability to ask for a re-negotiation
> of the session ID / Keys? Is it the client or the server or both? I
> would expect the server to be in control of such negotiation right?
Either side can always cause a new Session ID to be used in any handshake.
The client forces a new Session ID by doing any of the following:
- sending an SSL v3 hello message in the v2 format.
- sending an SSL v3 hello message with an empty, or zero, or unrecognized
SSL v3 session ID number
In any of these cases, the server is unable to reuse the session ID given
by the client, and so makes up a new session.
The server also has the freedom to choose to use a new session any time
it wants. It can always do a "full handshake" instead of a shorter
session "restart" handshake, and thereby start a new session.
--
Nelson Bolyard Sun / Netscape Alliance
