CODEWITHSUNDEEP
sessionsslhttpslifetime
Jens Schauder
Jens Schauder

Reputation: 81940

Lifetime of the SSL session in https

We have an engaged (but friendly) discussion between coworkers about the life time of the SSL session underlying a https communication.

When I establish a https connection to a server using a normal browser the underlying ssl creates a session (including a shared secret) using asymmetric encryption, the rest of the communication is encrypted using (faster) symmetric encryption.

The question is: On a subsequent https requests (click on a link) to the same server, is the old ssl session used again, avoiding the overhead of the asymmetric encryption for establishing a session key? Or is a new asymmetric encrypted ssl handshake for establishing a ssl session necessary?

Or to word it differently: Does a SSL session stays alive between https requests, or does it end with the end of the https request?

Since we are a bunch of nitpicks over here a reference to some authorative source would be apreciated.

Upvotes: 15

Views: 19249

Answers (3)

PressingOnAlways
PressingOnAlways

Reputation: 12356

Tested this out with Chrome:

navigate to https://www.americanexpress.com. netstat shows:

$ netstat -n -p tcp|grep 184.86.149.155
tcp4       0      0  10.177.78.58.50311     184.86.149.155.443     ESTABLISHED
tcp4       0      0  10.177.78.58.50310     184.86.149.155.443     ESTABLISHED
tcp4       0      0  10.177.78.58.50309     184.86.149.155.443     ESTABLISHED

On navigating to other links on the website, netstat shows:

$ netstat -n -p tcp|grep 184.86.149.155
tcp4       0      0  10.177.78.58.50311     184.86.149.155.443     ESTABLISHED
tcp4       0      0  10.177.78.58.50310     184.86.149.155.443     ESTABLISHED
tcp4       0      0  10.177.78.58.50309     184.86.149.155.443     ESTABLISHED

The session was kept alive. When I closed the browser tab, and re-opened the tab, another connection was opened:

$ netstat -n -p tcp|grep 184.86.149.155
tcp4       0      0  10.177.78.58.50398     184.86.149.155.443     ESTABLISHED
tcp4       0      0  10.177.78.58.50311     184.86.149.155.443     ESTABLISHED
tcp4       0      0  10.177.78.58.50310     184.86.149.155.443     ESTABLISHED
tcp4       0      0  10.177.78.58.50309     184.86.149.155.443     ESTABLISHED

It would appear that modern browsers utilize the same keep-alive timeouts as http. These timeouts can be viewed here:

http://gabenell.blogspot.com/2010/11/connection-keep-alive-timeouts-for.html

Upvotes: 12

MarkR
MarkR

Reputation: 63548

If your browser supports session resuming and the server has cached the session, then you may be able to continue a session between connections, GNUTLS supports this and you can see a demo here:

https://test.gnutls.org:5556/

Upvotes: 3

Andrew McGregor
Andrew McGregor

Reputation: 34612

See section 2.2 of http://www.ietf.org/rfc/rfc2818.txt and section 8.1 of http://www.ietf.org/rfc/rfc2616.txt

In essence, the SSL session SHOULD be maintained while the client maintains a persistent connection.

For more information about the implementation of persistent connections in popular browsers see http://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers

Upvotes: 5

Related Questions