[stunnel-users] permanent tunnel
Michal Trojnara
Michal.Trojnara at mirt.net
Mon Nov 1 13:18:52 CET 2004
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 31 of October 2004 02:49, Ramin Ali Dousti wrote:
> OK. Can you please explain how that works, I mean, The encapsulated TCP
> connection ends and let's say
> some 2 minutes later the client initiates another TCP connection with
> another client port number which goes
> through the stunnel again. At this point the server expects to do the
> SSL handshake again. From what you say,
> I gather that there is this "session cache" option which instructs the
> server to use its cache for the session key
> and not go through the whole SSL handshake. First of all, how is this
> cache maintained because it sounds like
> defeating the purpose of using SSL (and its handshake) once you rely on
> some kind of cache? Secondly, does
> the client not have to know about this mechanism? What is the dialog
> between the client and the server in
> maintaining the session key across multiple sessions?
- From RFC 2246 - The TLS Protocol Version 1.0:
When the client and server decide to resume a previous session or
duplicate an existing session (instead of negotiating new security
parameters) the message flow is as follows:
The client sends a ClientHello using the Session ID of the session to
be resumed. The server then checks its session cache for a match. If
a match is found, and the server is willing to re-establish the
connection under the specified session state, it will send a
ServerHello with the same Session ID value. At this point, both
client and server must send change cipher spec messages and proceed
directly to finished messages. Once the re-establishment is complete,
the client and server may begin to exchange application layer data.
(See flow chart below.) If a Session ID match is not found, the
server generates a new session ID and the TLS client and server
perform a full handshake.
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Fig. 2 - Message flow for an abbreviated handshake
I strongly recommend reading the whole document:
http://www.faqs.org/rfcs/rfc2246.html
Best regards,
Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBhimw/NU+nXTHMtERAsEeAKD9sMqagjSsjhA2Qg7qhUFbTRIBFwCeNXt0
iHxTenUFIs5i3/YGGNM5DRM=
=3z1q
-----END PGP SIGNATURE-----
More information about the stunnel-users
mailing list