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

[Michael D'Errico <[e-mail]>]

I haven't gone through this in detail, but one problem I see is
that it is the client that chooses the session ID for a resumed
session when a session ticket is used.  In fact the first (full)
handshake doesn't even have a session ID!

Of course the server can stick whatever identifiers it wants in
the ticket (since it is opaque to the client), so this might not
be a big deal.

Mike



Nico Williams wrote:
> 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