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

From: Nico Williams <[email-masked]>
Date: Wed, 28 Sep 2011 15:10:11 -0500

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
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Sep 2011 00:01:09 +0300

Hi Nico

> stack (including any concentrators);

If the server-side HTTP stack has that, why would such an application even need cookies? Cookies are generally keys to a saved server-side state. If you have access to the TLS session ID, you might as well use that as the key to the saved server-side state.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Wed, 28 Sep 2011 16:05:06 -0500

> If the server-side HTTP stack has that, why would such an application even need cookies? Cookies are generally keys to a saved server-side state. If you have access to the TLS session ID, you might…

This is true.  And if that's the end state, so much the better.  But
so much of the web depends on cookies that an incremental solution
that doesn't do much violence to the stack would be nice.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 28 Sep 2011 14:10:47 -0700

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

---

From: Marsh Ray <[email-masked]>
Date: Wed, 28 Sep 2011 16:20:38 -0500

On 09/28/2011 04:01 PM, Yoav Nir wrote:
>
> If the server-side HTTP stack has that, why would such an application
> even need cookies? Cookies are generally keys to a saved server-side
> state. If you have access to the TLS session ID, you might as well
> use that as the key to the saved server-side state.

It seems that most web apps are developed using some type of framework. 
These frameworks are often optimized for the plain-HTTP case.

Often HTTPS, and the certs, etc. aren't brought in until somewhat late 
in the development process. Apps get developed using cookies, then 
(occasionally) deployed with TLS as an encrypted tunnel for security. So 
we end up with all these insufficiently-bound channels needing channel 
binding.

When apps are developed with using TLS from the beginning, the result 
ends up looking much more integrated. But we also need to look for 
solutions that benefit all the other apps out there.

- Marsh

---

From: Nico Williams <[email-masked]>
Date: Wed, 28 Sep 2011 18:05:43 -0500

> the ticket (since it is opaque to the client), so this might not

At first glance this is a real problem, but in fact, it makes no sense
for the TLS server to report any session ID selected by the client --
whatever security value a TLS session ID might have had before
RFC4507, it'd have none now.

However, precisely because of this, what the server should do is
substitute, in any APIs, a server-generated session ID stored in the
ticket.  The session ID that goes on the wire is pretty much
irrelevant (though it's always possible that some application protocol
references TLS session IDs on the wire, I rather doubt this).

This would mean, possibly, changing TLS server implementations that
support RFC4507, which is less advantageous than I'd hoped for.

Nico
--

---

From: Tom Ritter <[email-masked]>
Date: Wed, 28 Sep 2011 19:34:34 -0400

I don't think this would work in the (common) case of ssl
accelerators/forwarders and reverse proxies.  The app just sees HTTP,
there's no ssl from the point of view of the framework/code a developer
wrote.

-tom

---

From: Nico Williams <[email-masked]>
Date: Wed, 28 Sep 2011 19:26:02 -0500

> there's no ssl from the point of view of the framework/code a developer

They generally add headers to a request, and communicate details of
the TLS connection via those headers.  For example:
http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_ssl_profiles.html
 (search for "header").

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 29 Sep 2011 04:41:51 +0200 (MEST)

> there's no ssl from the point of view of the framework/code a developer

+1

I also do *NOT* want to see any server-side apps to mess/interfere with
TLS session cache management (size and lifetime) on my server or on
whichever backend border component (accelerator/forwarder/rev.proxy)
the SSL session is "first opened".

There is also no guarantee that all client components, that are part
of an application client infrastructure and consciously sharing
HTTP cookies, are accessing the same TLS client implementation and
sharing the TLS session cache.

-Martin

---

From: "Steve Dispensa" <[email-masked]>
Date: Wed, 28 Sep 2011 22:08:59 -0500

> Martin Rex wrote:

Apart from this objection, how would this proposal work with expiring
(long-duration) cookies? There are plenty of apps with "remember me"
checkboxes.

But regarding the hardware accelerators, to whatever extent this idea is
valid going directly to a server, they would be able to apply the same
binding themselves without the cooperation of either server or client.
Other problems have been noted, but accelerators don't represent a
critical problem.

I like the thinking in this idea, though. I wonder if there is a
meaningful subset of cases for which this would work, or if Martin's
concerns vis-a-vis the client side are fatal.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 29 Sep 2011 08:38:16 +0200

> Mine: use TLS session IDs as the channel binding.
[...]
> Disadvantages:

One additional disadvantage I see is that you lose perfect forward
secrecy. The usage of resumption ensures that the same keys are re-used
for the same peer again and again.

regards,
Nikos

---

From: Florian Weimer <[email-masked]>
Date: Thu, 29 Sep 2011 10:52:08 +0000

> Mine: use TLS session IDs as the channel binding.

If we're interested in working around the cookie issue (as opposed to
fixing the protocol issue), I think it would be simpler to include a
random prefix in the cookie, ignored by the server, and the server would
change the prefix every few requests.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Nico Williams <[email-masked]>
Date: Thu, 29 Sep 2011 09:25:20 -0500

> change the prefix every few requests.

I don't see how that would stop BEAST.  And, in any case, would
require changes to clients and servers both, which makes it much
harder to deploy.

Nico
--