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

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Oct 2015 15:05:31 -0700

https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone-01

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.

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.

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.

Either way, I'd support working on neutering this class of attacks.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 22 Oct 2015 07:44:06 +0200

Hi Martin,

> compatibility issues.  But I do prefer the change in the draft, if it

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

Willy

---

From: Mike West <[email-masked]>
Date: Thu, 22 Oct 2015 13:26:47 +0200

Thanks for noting this, Martin. I somehow didn't think to ping these
drafts to the list.

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

> non-trivial amount of bustage will likely prevent us from deploying a

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

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

-mike

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 22 Oct 2015 13:47:20 +0200

Hi Mike,

> About that... https://tools.ietf.org/html/draft-west-origin-cookies-01

Interesting idea.

> for folks to start playing with.

This one is indeed less invasive than the first one as it continues to
respect the same header name for example.

Thanks for the explanations.
Willy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Oct 2015 09:56:45 -0700

> current cipher-suite deprecations seem like a reasonable model to

I had hoped that would wouldn't need to resort to that.  Of course, if
we can agree to do so, then I'm all over it.

At less than 0.05% I think that I could probably tolerate breakage.