W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: draft-west-leave-secure-cookies-alone

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 22 Oct 2015 07:44:06 +0200
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Mike West <mkwst@google.com>
Message-ID: <20151022054406.GC4405@1wt.eu>
Hi Martin,

On Wed, Oct 21, 2015 at 03:05:31PM -0700, Martin Thomson wrote:
> The authors of the paper recommended that non-secure cookies be simply
> given less precedence, so that they could not override cookies set by
> their secure brethren.  That seems far less likely to cause
> compatibility issues.  But I do prefer the change in the draft, if it
> can be made to stick.

I do think as well that there are little risks. The corner case I'm
thinking about is when cookies are used for load balancing. I know
a number of places where the cookie is relied on to maintain the
stickiness between the HTTP and HTTPS sites. So the first cookie is
assigned when you visit the HTTP site, which quickly drives you to the
HTTPS site on the same server. The issue I'm seeing is that when the
server dies, the user must be brought to another server and here we
want to be sure that it is possible to change the server from the
HTTP site after it's been used for HTTPS. The good thing is that I
don't see a reason why a load balancer would pass the "secure" flag
on a stickiness cookie, so I think this should mostly be safe.

However in my opinion this proposal will not protect at all against
cookie injection before the first visit of the site. This is often
done by bringing the visitor to an unrelated site and injecting a
cookie that will be delivered to the target site after the visitor
goes there (through a link, redirect or JS url change).

I think in fact that what we're missing is the ability for the
browser to tell the server how it considers the cookie (secure or
not). The servers could then decide to ignore non-secure cookies
in this case and that would protect much better, including against
cookie injection. That would require updating the cookie syntax and
spec though since we can't pass attributes with cookies :-/

Received on Thursday, 22 October 2015 05:44:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC