[stunnel-users] permanent tunnel

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-----