Re: Cookies and schemes.

Mike West <> Sun, 15 March 2020 08:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6890D3A120D for <>; Sun, 15 Mar 2020 01:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.251
X-Spam-Status: No, score=-10.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X00hf1T1z1zz for <>; Sun, 15 Mar 2020 01:26:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02AAA3A120E for <>; Sun, 15 Mar 2020 01:26:24 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jDOY7-0000Xa-0c for; Sun, 15 Mar 2020 08:23:07 +0000
Resent-Date: Sun, 15 Mar 2020 08:23:07 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jDOY2-0000Wj-Gu for; Sun, 15 Mar 2020 08:23:02 +0000
Received: from ([2a00:1450:4864:20::12e]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jDOY0-0004OE-A5 for; Sun, 15 Mar 2020 08:23:02 +0000
Received: by with SMTP id t21so11357266lfe.9 for <>; Sun, 15 Mar 2020 01:22:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3+TO3FRnMc3Lm6jK+BgI3pUpk1CvSVyjSAfKZZ/Zh4c=; b=abHfZcdxVhLGOawJ+nRkU/P30yIOEF6dQqjY/uyGuvYyJny7a3OZxAXG+UgS2km0Xi FoBbwMihwPwhmjHYfLWNfIbkkpaoKOEIjv8q0eRYBIKATIvMP1f/IlRMwo6IJ7F9eZWE 27GeeuF54HX7YcEhTONRZO7Z40QtMLQFB9aQSM+X3a5QgbHLsI8ZT73TXOZIOrimq9Nm HpQHyH20ihy9ORsyrYl2tYW2Ry1rGnWZwI3DYTLPMNPZJar4nJsR7gloLYvyYLoY4U+Q c9ZphcD6BkD5l0SQHYVcgjB+LjuLxiEZUZsR5aKKYik/yzXibyu01T8JJfRHr3NUUJzg CXpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3+TO3FRnMc3Lm6jK+BgI3pUpk1CvSVyjSAfKZZ/Zh4c=; b=Bg01xnoGXqVHqEWQjWV5fhK8S2c02Ua5Opz7mUlsQ4QHmLLhpnsiuPy292jPdd3AKp 25JKDYcbXahy38XPvtojobXZgHSEDdxczDT8YUxDYF3VFYKyxCsAQRgvypCk0GDPi6uP L5ge83khpQf5WaOocxUMtezPIUA9PwUw2rHur+oEZDXCkRVEYUJwLBFk3cTwMCBd0bZ3 jGT6m8ELj4wv7IAk4brk5ZchJmqFFShxzZsBeJVennZqQ6ixPO6sj5kyhBeNWtuylNCx dzkexkpfgc2lOQAGbuZIrEbrWYY1QG8PZN+avTT6hxq40xnq3ZZ2ZtU/XBixjCYvnf07 7/GQ==
X-Gm-Message-State: ANhLgQ31zsX++FtkIqnRJlxI9/rzNWWAydTiBR39Ek0kXL0zOraii8E1 ypWmGb0Av5469wyuEV8FyumPF7XU0bR6y/46XZ5+2w==
X-Google-Smtp-Source: ADFU+vt1U20AXrPfL3kAzEEGOGIySzw0at6NEYiTQKEN7eskS/DbJYNTxRpLjJLbtV6thURVIA0EEkWLT0VGA/we344=
X-Received: by 2002:a19:8a02:: with SMTP id m2mr13500155lfd.53.1584260568127; Sun, 15 Mar 2020 01:22:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Mike West <>
Date: Sun, 15 Mar 2020 09:22:36 +0100
Message-ID: <>
To: Willy Tarreau <>
Cc: Martin Thomson <>, Steven Bingler <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000006571b205a0e068bc"
Received-SPF: pass client-ip=2a00:1450:4864:20::12e;;
X-W3C-Hub-Spam-Status: No, score=-24.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jDOY0-0004OE-A5 def4f89dfa61be7e4d04e4ca988cd988
Subject: Re: Cookies and schemes.
Archived-At: <>
X-Mailing-List: <> archive/latest/37442
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hey folks,

I sketched out changes in a little more detail in an -01 of That
sketch doesn't include either `__Nonsecure-` or `Sec-Nonsecure-Cookie`, as
I agree with Martin's suggestion that we should avoid them if possible. It
might be better for any such mitigation to live as a UA-specific workaround
rather than part of the core specification.

That said, I think I also agree with Willy's implicit claim that they will
be necessary for some period of time. The general experience we've had with
recent deprecations is that despite our best efforts, developers do not get
the message until we begin deploying a change. It seems quite reasonable to
me to plan for a multi-stage deprecation to minimize the potential for data
loss. That's almost certainly the path we'd try to take in Chromium. Other
user agents might be interested in being more aggressive.

Thanks again for the feedback! Willy, I'll pull out a few specific points
to respond to below:

On Tue, Mar 10, 2020 at 9:51 PM Willy Tarreau <> wrote:

> On Tue, Mar 10, 2020 at 08:29:50AM +0100, Mike West wrote:
> > 2.  It does not put those cookies into the `Cookie` header, meaning that
> a
> > host that doesn't intentionally perform a migration (and, in the best
> case,
> > validate the data against whatever securely-delivered state it has access
> > to before blindly accepting it) won't be at risk.
> It will be worse. Those having trouble configuring them will modify their
> LBs to put everything into cookie and systematically duplicate them into
> the other ones, considering that "the browser will figure which one it
> needs anyway".

I agree that this is likely, which is why I think it's important that any
stopgap is as short-lived as possible. The only way to ensure that
non-securely-set cookies can't influence the state of a secure site is for
the browser to stop sending them in any form. We should aim for that state
as quickly as practicable.

> If I understand the redirect proposed above, it would give network
> > attackers the ability to send arbitrary cookies to secure servers by
> > forging HTTP responses that set cookies and redirect to HTTPS. I'd like
> to
> > remain robust against this kind of attack.
> It's already the case by definition as long as the transmission operates
> in clear. Anything can be put in the response, including some links or
> whatever. If you have data showing that cookies are not passed anymore
> cross redirects from HTTP to HTTPs, then that's fine and it means that
> we don't need this anymore. But I never received complaints that haproxy
> started to lose affinity on redirects, which makes me think it's still
> valid.

I agree that this kind of redirect works well in the status quo. This
proposal explicitly aims to break it in the future, as it seems bad for an
otherwise-secure site to be forced to trust data created over a non-secure

You're correct to say that there's little the browser can do to prevent a
non-secure site from sharing data with a secure site via other means (URL
parameters, server-to-server communication, etc). I don't think that kind
of one-off capability is a reasonable argument for baking that attack into
the state management mechanism that user agents offer as part of the

> > 2.  Perhaps we prefix the non-secure cookie names with `__Non-secure-`
> > rather than minting a new header?
> I really like this. It's by far the easiest solution. Usually nobody
> cares about the load balancer's cookie name because the LB will remove
> it before passing the request to the server, so this one can be changed
> at will by the person responsible for the LB. There are always edge
> cases of course, like a management page hosted on the application to
> perform some specific tests or maintenance operations but the 1% doing
> this know exactly what they're doing and will figure a different way
> to do it.

For clarity: I did not intend for these cookies to stick around. I intended
this as a temporary carveout for applications to migrate their user data
from HTTP to HTTPS, not as something that would stick around in perpetuity.
Just as we don't allow `` to share `localStorage`,
databases, caches, etc with ``, I don't think there is
a good long-term solution for writing cookies in a non-secure context that
are trivially legible in a secure context.

The problem is that by breaking 10% of the web every 3 months we're
> making everyone totally incompetent on infrastructure, rendering the
> whole web totally insecure. I'd rather use motivation that trouble
> making. Using the cookie name is perfect because it is visible in the
> browser. So when your site requires that all your users see they learn
> cookies called "insecure_something", you do have a great motivation to
> try to improve the situation without being forced to rush an even more
> horribly insecure hack to suit a browser's next imposed deadline that
> threatens to destroy your site.

We do need to come up with reasonable timelines for deployment if we agree
that this is the right direction in which to move. I am sympathetic to the
concern that we're dripping out changes over time, and it might well be
worthwhile to bundle up larger sets of changes so that developers can
respond to them at once.

> > I don't think we should add new attributes in order
> > to support sites that push users back and forth from HTTPS to HTTP.
> I think that once the cost of switching the connection to HTTPS has been
> digested, there's no point in going back to HTTP from HTTPS. However,
> easing the transition from HTTP to HTTPS seems very important to
> encourage migrating ealier in the session, even if reaching that
> state requires several baby steps from the site's operator.

My intuition is that we're already pushing pretty hard on HTTP->HTTPS
migrations, and have built several tools over the past few years to help
both inside (`Upgrade-Insecure-Requests`, CSP reporting for `http:`
resources, "Not Secure" labels, etc) and outside (search console warnings,
various scanning/rating tools, etc) browsers.

At the same time, we really need to remove residual risk from non-secure
channels. The proposal in the document we're discussing seems to me a
reasonable compromise: non-secure channels are segregated from secure
channels, and only have access to temporary client-side state. This will
sincerely narrow the window of opportunity for network attackers, without
entirely breaking things like your printer's web interface.

I welcome feedback about the balance that compromise strikes. I'm certain
there are ways to tweak it that will have better results for all sides. I'm
reluctant to do so in ways that allow developers to continue pretending
that shipping non-secure sites is acceptable, but I think there's
substantial willingness to find solutions deployable in the short-term.

Thanks again for y'all's comments!