[prev in list] [next in list] [prev in thread] [next in thread] 

List:       stunnel-users
Subject:    Re: [stunnel-users] permanent tunnel
From:       Michal Trojnara <Michal.Trojnara () mirt ! net>
Date:       2004-11-01 12:18:52
Message-ID: 200411011319.09599.Michal.Trojnara () mirt ! net
[Download RAW message or body]

-----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-----
_______________________________________________
stunnel-users mailing list
stunnel-users@mirt.net
http://stunnel.mirt.net/mailman/listinfo/stunnel-users

[prev in list] [next in list] [prev in thread] [next in thread]