-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Saturday 30 of October 2004 01:16, Ramin Ali Dousti wrote:
You're right in that I don't have persistent TCP connection. I just want to make sure that the SSL handshake does not take place with every short-lived connection.
You don't want to negotiate new keys for every connection, right?
In SSL there's a mechanism for it called "session cache". In stunnel you can increase the timeout for session cache with "session" option (on both client and sever). Just set it to a very high value (a month? a year?). The default is 300 seconds (5 minutes).
Best regards, Mike
Michal Trojnara wrote:
On Saturday 30 of October 2004 01:16, Ramin Ali Dousti wrote:
You're right in that I don't have persistent TCP connection. I just want to make sure that the SSL handshake does not take place with every short-lived connection.
You don't want to negotiate new keys for every connection, right?
In SSL there's a mechanism for it called "session cache". In stunnel you can increase the timeout for session cache with "session" option (on both client and sever). Just set it to a very high value (a month? a year?). The default is 300 seconds (5 minutes).
Best regards, Mike
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?
Thanks for the help.
Ramin
-----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
-
Michal Trojnara -
Ramin Ali Dousti