Http persistent connection and ssl session?

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 ietf.org/rfc/rfc2246.txt F.1.4 for technical details on resuming.

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 ietf.org/rfc/rfc2246.txt, F.1.4 for technical details on resuming.

Eugene:After the handshake, SSL peer parts have the information needed to establish the secure channel(encrypt/decrypt) since security details have been exchanged (algorithms etc). This part as I understand it, seems irrelevant to the underlying tcp connection which get the encrypted blocks and transmits them over the socket. How come the tcp connection that closes, invalidates the previously agreed security details of the ssl parties (client/server)?

This part I do not understand. Could you please elaborate? – user384706 Jan 16 at 14:14 @user384706 From technical point of view SSL/TLS doesn't care about connection and can be used over UDP (in case of UDP the modification of TLS is used, named DTLS), named pipes, pigeon mail etc (we once implemented it over message-based communication channel).

However, it's agreed that to prevent certain attacks disconnection of underlying channel automatically invalidates SSL connection as well. In general nothing forces you to do this if you implement both client and server side of communication and you control SSL functions as well (eg. When using our components).

– Eugene Mayevski 'EldoS Corp Jan 16 at 14:25 @Eugene:So it is best practice to consider the TLS session invalidated? It is not mandated by any RFC or is not implied by TLS RFC, right? – user384706 Jan 16 at 14:28 @user384706 personally I don't know of closing of TLS connection is mandatory when underlying transport connection is closed, but there can be some attack based on this.

I think this is a good topic for a separate deeper investigation. – Eugene Mayevski 'EldoS Corp Jan 16 at 14:50 @Eugene:I opened stackoverflow. Com/questions/4705715/… for this.

Concerning this thread, should I assume the best I could do is set a high keepalive timout in server? – user384706 Jan 16 at 14:58.

publib.boulder.ibm.com/httpserv/ihsdiag/... : 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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.