Re: [TLS] Session Lifetime

Marsh Ray <> Mon, 29 November 2010 21:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BE6028C0D7 for <>; Mon, 29 Nov 2010 13:19:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.576
X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eVqL+P3Qyv+i for <>; Mon, 29 Nov 2010 13:19:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5160928C0CE for <>; Mon, 29 Nov 2010 13:19:05 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1PNB8x-000Opc-E0; Mon, 29 Nov 2010 21:20:15 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 7A4B06018; Mon, 29 Nov 2010 21:20:12 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19GETp8563V4f8vEcdThV6deFbLnB8k74U=
Message-ID: <>
Date: Mon, 29 Nov 2010 15:20:12 -0600
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.0.10
MIME-Version: 1.0
To: Seth David Schoen <>
References: <> <> <> <20101129175911.GA19368@sescenties>
In-Reply-To: <20101129175911.GA19368@sescenties>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Session Lifetime
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Nov 2010 21:19:11 -0000

On 11/29/2010 11:59 AM, Seth David Schoen wrote:
> One concern is that resumed sessions work like cookies to identify
> users, but users may not have convenient ways to control them as
> they can control cookies.  There has been recent concern about
> browser functionality that is equivalent to HTTP cookies but not
> subject to user control like cookies.

I agree that this is important. An unauthenticated active attacker can 
query your browser to find out if you've contacted specific servers 
recently. It reveals information in-the-clear.

I'm not aware of any client implementations that persist sessions across 
a browser restart. (Scratch that - testing with a friend who has one of 
those phones that start with a lower-case letter showed that even 
"exiting" the browser, locking the phone, etc. would not clear session 
cookies.) With all the trouble can takes to get session resumption to 
happen effectively in application code, it never seemed like a big deal 
in practice. An https site was one that you probably wanted to 
authenticate to anyway.

But things have changed. TLS clients are on phones now and may stay 
running in the background for long periods. Unlike computers of old 
(battery^network), mobiles may initiate a session from a trusted network 
and then later connect to an untrused network.

Say an attacker wishes to penetrate He hangs out in a 
coffee shop across the street with a wifi device in his pocket. He 
conducts an active attack on random nearby wifi devices using 
established techniques. An at the coffee shop loads an 
unencrypted web page. Attacker inserts innocuous resource load from the 
target server "", attacker observes TLS 
Client Hello offering resumption. The attacker has strong evidence that 
this computer belongs to a targeted user and the browser probably has 
session cookies for internal applications. If bugzilla hasn't set its 
session cookie to secure, the attacker can obtain it by injecting a 
request for a resource from the unencrypted .

This is not really a new attack, and there are other ways to fingerprint 
the target machine (it's probably broadcasting around for anyway). But the resumption is a contributing 
factor. Note that neither the user nor the network firewall sees any 
suspicious packets in this attack.

Perhaps the only fix would be for clients to cut the resumption time 
down to a minute or two (after closing the last active socket maybe?). 
If the majority of resumptions are simply browsers opening multiple 
connections anyway, this might not have too bad an effect on resumption 

- Marsh