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

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

From: Mike West <mkwst@google.com>
Date: Thu, 22 Oct 2015 13:26:47 +0200
Message-ID: <CAKXHy=dAc3bnyTMadVr_8q+2mBFMeuVAx4FzDsnKaFDS3MrvTQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>, w@1wt.eu
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Thanks for noting this, Martin. I somehow didn't think to ping these
drafts to the list.

On Thu, Oct 22, 2015 at 12:05 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> I realize that we haven't discussed this at all, but it seems like a
> no-brainer to me.  That is, if someone (Mike?) has a satisfactory
> answer to this question: do you know what level of breakage is this
> going to cause?  I have heard that this misfeature is relied upon by
> some non-trivial number of sites.

Chrome sees something like 0.01% of `Set-Cookie` operations fall into
the category that this draft suggests ignoring.

Mozilla has similar metrics hovering around 0.02%.

> For me, as long I can be satisfied that the breakage is extremely low,
> or that it will soon be, then that's sufficient.  However, a
> non-trivial amount of bustage will likely prevent us from deploying a
> change like this.

I think we can mitigate the impact by rolling this kind of change out
in a somewhat coordinated fashion, and announcing it beforehand. The
current cipher-suite deprecations seem like a reasonable model to

On Thu, Oct 22, 2015 at 7:44 AM, Willy Tarreau <w@1wt.eu> wrote:
> 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 :-/

About that... https://tools.ietf.org/html/draft-west-origin-cookies-01
is one approach.
https://tools.ietf.org/html/draft-west-cookie-prefixes-04 is another
(and has the advantage of being trivial to implement). Chrome's
implemented the latter (at least the `$Secure-*` prefix) behind a flag
for folks to start playing with.

Received on Thursday, 22 October 2015 11:27:39 UTC

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