http persistent connection and ssl session

问题:

HTTP is an application protocol and the underlying TCP connection could be closed and reopen without affecting the HTTP application (except performance).
By using HTTP1.1 we use persistent connections but still a server or client could close the connection at any time.
For security HTTP uses TCP via SSL/TLS.
My understanding is that SSL acts much like an application, at least this is how TCP "views" SSL.
My question is if the underlying TCP socket closes at a point after the secure connection has been established, does this mean that the SSL session becomes invalid and the parties should start over the ssl handshake?
Or the underlying TCP connection is irrelevant to the TLS session?

Thanks!

回答1:

does this mean that the SSL session becomes invalid and the parties should start over the ssl handshake?

Yes, the SSL/TLS session is over and handshake must be re-established. TLS includes mechanisms for resuming the session (there still will be some operations performed, but less than in full handshake), but not all applications support it.

See http://ietf.org/rfc/rfc2246.txt, F.1.4 for technical details on resuming.

回答2:

http://publib.boulder.ibm.com/httpserv/ihsdiag/ihs_performance.html#SSL :

An SSL session is a logical connection between the client and web server for secure communications. During the establishment of the SSL session, public key cryptography is used to to exchange a shared secret master key between the client and the server, and other characteristics of the communication, such as the cipher, are determined. Later data transfer over the session is encrypted and decrypted with symmetric key cryptography, using the shared key created during the SSL handshake.

The generation of the shared key is very CPU intensive. In order to avoid generating the shared key for every TCP connection, there is a capability to reuse the same SSL session for multiple connections. The client must request to reuse the same SSL session in the subsequent handshake, and the server must have the SSL session identifier cached. When these requirements are met, the handshake for the subsequent TCP connection requires far less server CPU (80% less in some tests). All web browsers in general use are able to reuse the same SSL session. Custom web clients sometimes do not have the necessary support, however.