[TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs

[Nico Williams <[e-mail]>]

A while back Dirk Balfanz proposed something he called "origin bound
certificates" and "channel bound cookies".  A lighter-weight
alternative (i.e., involving no protocol changes) would be nice.
Mine: use TLS session IDs as the channel binding.

Suppose you have a server with a TLS stack that generates nice, large,
[pseudo-]random TLS session IDs, and that supports session resumption
(preferably with session tickets).  Now have the app's login page bind
the TLS session ID into the cookies it generates for the user's
application session.

So, if a cookie consists of E(app_service_key, username ||
app_session_data) now make it E(app_service_key, username ||
app_session_data || tls_session_id).  Similarly for other cookie
construction techniques.

And, critically, change the cookie validation code to check that the
TLS session ID of the connection over which a request was received
matches the cookie's binding.

This is a pure server-side fix for cookie theft attacks, including BEAST.

Pre-requisites for this concept to be workable:

 - client support for TLS session resumption (preferably also with
support for session tickets);
 - server (concentrator!) support for session resumption (preferably
also with ...);
 - TLS session lifetimes matched to cookie lifetimes;
 - TLS session IDs must be exposed up the TLS and HTTP server-side
stack (including any concentrators);
 - TLS servers that generate large session IDs (32 bytes is the max)
using a suitable [P]RNG.

Advantages:

 - purely server-side solution;
 - does minimal violence to web applications (only cookie generation
and validation are affected);
 - can be deployed at any rate;
 - no standards-work is required because no protocols are modified
(except, perhaps, in the form of a BCP that we might want to issue
describing this, and maybe a new header by which the server can
advertise that it's channel binding cookies);
 - some web server frameworks will probably be able to implement
channel bound cookies transparently to the server application;
 - RFC5056-compliant.  :)

Disadvantages:

 - not all server stacks will meet the requirements listed above on day 1;
 - we may need a method for detecting clients that don't support
session resumption, if there exist such clients (which I'm sure is
true); however, if such detection can be done from, say, the
user-agent string sent in an HTTPS request (say, the login form POST),
at least we won't have a downgrade attack.

Can this work?  Or is my feverish imagination misleading me?  I think
it can work.

Yes, there's a concern over collisions in the session ID space, but
it's up to 256-bits.  It suffices that attackers not have any way to
force a TLS session's ID to match another's.  So I don't think this is
a concern.

It'd be nice, too, if the server could advertise to the user-agent
that its cookies are channel bound, so the user-agent can apply policy
requiring channel bound cookies if it wishes.

Nico
--