Subject: [TLS] TLS session resumption lifetime

From: "Andris Berzins" <[email-masked]>
Date: Fri, 22 Feb 2013 13:25:00 +0200

Hello,

Can anyone comment whether TLS session lifetime is enforced by browsers?

Thank you!

---

From: [email-masked] (Martin Rex)
Date: Fri, 22 Feb 2013 22:26:20 +0100 (CET)

Andris Berzins wrote:
>
> Hello,<br /><br /> <div id="sig_upper">&#160;</div><div id="sig_lower">&#160;</div>Can anyone comment whether TLS session lifetime is enforced by browsers?<br /> <br />Thank you!

What exactly do you mean with "TLS session lifetime is enforced by browsers"?

There is only a _suggestion_ to not cache TLS session for more than
24 hours in TLSv1.0 (rfc2246).  Often, servers may expire TLS sessions
from the server side cache much earlier (our server uses a session cache
lifetime of only 24 minutes by default).

  http://tools.ietf.org/html/rfc2246#section-7.4.1.2

   7.4.1.2. Client Hello
  [...]

   The client hello message includes a variable length session
   identifier. If not empty, the value identifies a session between the
   same client and server whose security parameters the client wishes to
   reuse. The session identifier may be from an earlier connection, this
   connection, or another currently active connection. The second option
   is useful if the client only wishes to update the random structures
   and derived values of a connection, while the third option makes it
   possible to establish several independent secure connections without
   repeating the full handshake protocol. These independent connections
   may occur sequentially or simultaneously; a SessionID becomes valid
   when the handshake negotiating it completes with the exchange of
   Finished messages and persists until removed due to aging or because
   a fatal error was encountered on a connection associated with the
   session.

  http://tools.ietf.org/html/rfc2246#appendix-F.1.4

   F.1.4.  Resuming Sessions
  [...]

   Sessions cannot be resumed unless both the client and server agree.
   If either party suspects that the session may have been compromised,
   or that certificates may have expired or been revoked, it should
   force a full handshake. An upper limit of 24 hours is suggested for
   session ID lifetimes, since an attacker who obtains a master_secret
   may be able to impersonate the compromised party until the
   corresponding session ID is retired.

The time of use of a TLS session on an established connection is independent
from the TLS session cache lifetime (the latter typically affects only
the possibility to resume a prior session on a new connection).

At least some browsers delete the TLS sessions from their TLS session cache
when a new connection, where TLS session resumption was proposed, is
aborted by the browser itself early during the handshake, e.g. du to a
user navigating to a new page before the current one has completed loading.
Active content on a page might also cause new TLS connections to be
killed during its infancy. 

-Martin

---

From: "Andris Berzins" <[email-masked]>
Date: Sat, 23 Feb 2013 02:46:18 +0200

Thank you Martin! So there is suggestion for client to enforce upper lifetime of 24 hours.

I know that Firefox clears TLS session cache when "Active logins" checkbox from "Clear all history" menu is 
checked.

Maybe someone from browser vendors can comment whether session cache expiration is enforced.

Quoting "Martin Rex" <[email-masked]>:
> Andris Berzins wrote:
>> 
>> Hello,<br /><br /> <div id="sig_upper"> </div><div id="sig_lower"> </div>Can
>> anyone comment whether TLS session lifetime is enforced by browsers?<br /> 
>><br />Thank you!
>