Re: [TLS] Session Lifetime

[Marsh Ray <[e-mail]>]

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 example.com. 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 example.com at the coffee shop loads an 
unencrypted web page. Attacker inserts innocuous resource load from the 
target server "https://bugzilla.example.com", 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 http://bugzilla.example.com/ .

This is not really a new attack, and there are other ways to fingerprint 
the target machine (it's probably broadcasting around for 
exchange.example.com 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 
rates.

- Marsh