Re: Cookies and schemes.

Mike West <> Tue, 10 March 2020 07:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9066A3A0CA5 for <>; Tue, 10 Mar 2020 00:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.25
X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 US1tDBXWu7Cz for <>; Tue, 10 Mar 2020 00:33:30 -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 4EFF73A0CA4 for <>; Tue, 10 Mar 2020 00:33:29 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jBZLP-0001xX-Cp for; Tue, 10 Mar 2020 07:30:27 +0000
Resent-Date: Tue, 10 Mar 2020 07:30:27 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jBZLE-0001wm-Qb for; Tue, 10 Mar 2020 07:30:16 +0000
Received: from ([2a00:1450:4864:20::229]) by with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1jBZLC-00024l-SW for; Tue, 10 Mar 2020 07:30:16 +0000
Received: by with SMTP id d12so12936143lji.4 for <>; Tue, 10 Mar 2020 00:30:14 -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=1rpuSb3eRow7g8TyQLN6tEYXxmNkDnQZeBxMC4os4Jk=; b=Sq8VbSrjI9mQw4kmgO/0yraz8GJ0T9Al08TaOXpWE4GUpP/S4baIPIyVfbbKwM/oMH O/5U7YIHLvjoRi2sUc7PfeABN6N+TBJ02+RrYkUhnm0mIg7qkPi+Y4VGcXKND5tS1Vci TZvWpCC2XZ/9fyg8dDGmX6KJqZIODk39DxT9cJ9FwQONlYKd8a63Y4Ns5qex8Z4qsfB4 QBgm/1vG48qHls+GVHrvSaxLoY+pxyRrTaUcARYdTmQZ7BRK0t6TJuewhY9v2/Fhc9T5 Rd4xjOoCVW1ueWGN3BDMXW13Bva4O8Ic0b2OAJpHoYRpKNTYu6AIK/4hQtFNEv28LeZ1 uW/g==
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=1rpuSb3eRow7g8TyQLN6tEYXxmNkDnQZeBxMC4os4Jk=; b=IQo1GWNZ/H8Y/2LfsBF62n+BWOBcURenguF/ZOgYzxhxnJUDD7BfACotaBrYn2Wkr8 yxM9PPYT/cY+C+G1NELTQ+LPPVtNRrRAZakZW9Qnmb1WENJ+TaSPbdEPwOZknPuT+wIX kx9Z868hGME48xje73OpomZiMovLBGWhjBDwnc7c5/n3Pl3v4cZj30Onl1uOl+WcI73D tS2aI2yjpVoVoLspvGjy6AVMNeG3pGFASg2qKyJDKsMAs1hj2wpEhz/6oKBlznjLQlT5 EfNXWdMAViIOtjYR+qNUO6mm+lo8NpONiXnIXacL3toVQyUmES+nYpQTwSya6PBrN7Pz 8N4A==
X-Gm-Message-State: ANhLgQ2XbjBEXzAOzj9713r6XcIeEsf6tcKEOxod3g6stMS/Fw+oHZRn vCof3DFKZeqQ0xER9k2IFEBjrIGJ8AO3PfhuhM2x4w==
X-Google-Smtp-Source: ADFU+vuAI30q9Wj4E4T6BTYweQ4b/ijU5LNP8H+o/Jgtu8cO+db9sdzP/oXH/Gsc6wcsqaPP6dF4Js1Qn1sSCzAiuMs=
X-Received: by 2002:a2e:151e:: with SMTP id s30mr6551530ljd.92.1583825401888; Tue, 10 Mar 2020 00:30:01 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Mike West <>
Date: Tue, 10 Mar 2020 08:29:50 +0100
Message-ID: <>
To: Martin Thomson <>, Willy Tarreau <>, Steven Bingler <>
Cc: HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000077fa0105a07b1685"
Received-SPF: pass client-ip=2a00:1450:4864:20::229;;
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: 1jBZLC-00024l-SW 848d6a88419b0013f6edeff4ca1be3ba
Subject: Re: Cookies and schemes.
Archived-At: <>
X-Mailing-List: <> archive/latest/37430
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks, Martin and Willy!

On Mon, Mar 9, 2020 at 11:07 PM Martin Thomson <> wrote:

> On Mon, Mar 9, 2020, at 19:51, Mike West wrote:
> > proposes two changes:
> >
> > 1. We teach cookies about schemes, and lock them to the scheme that set
> > them (just like every other web-facing storage mechanism).
> Excellent!
> To Willy's point about transfer, perhaps we can allow any cookies that are
> set on an http:// response to follow a redirect to https://  The
> Sec-Nonsecure-Cookie header field seems like it might not be great long
> term.

The `Sec-Nonsecure-Cookie` header is, indeed, not something we'd want to
keep for the long term. I'm thinking of it explicitly as a stopgap for the
period of time directly after we start enforcing scheme bindings, and would
expect it to live for a quarter or so. That said, I'm not amazingly
enthusiastic about it, but it has three properties I like:

1.  It gives secure hosts access to their non-secure cookies in a way that
allows them to perform a migration if they so desire.
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.
3.  It doesn't require us to figure out an ordering of "the same" cookie
that's distinguished only by scheme (e.g. `Set-Cookie: a=b` on both `` and ``).

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.

Two alternatives come to mind:

1.  Perhaps we do this kind of thing only for a specific endpoint
(`/.well-known/migrate-nonsecure-cookies`, for example)?
2.  Perhaps we prefix the non-secure cookie names with `__Non-secure-`
rather than minting a new header?

Both would require more explicit involvement from the server to perform the
migration, which I think is valuable.

> > 2. We curtail non-secure schemes' cookies' lifetime by agreeing on a
> > set of heuristics for a user's "session" on a given site, and culling
> > cookies when a site's session expires.
> Also good.  The need for heuristics is unfortunate, but I appreciate that
> you have to do that.

The heuristic described in the doc seems workable, and matches my
intuitions about user's understanding of session lifetimes (modulo a lot of
fuzziness around the exact time period after closing the last window). I
hope it's something that's deployable in practice.

On Tue, Mar 10, 2020 at 4:43 AM Willy Tarreau <> wrote:

> > Have I missed a key piece of information?  Willy, could this work in the
> > cases you understand?
> I think it can, yes, but it would still require some infrastructure
> adaptations, and by default could degrade the behavior over HTTPS by
> forcing to always append a cookie in response. The typical case I'm
> thinking about is the following sequence:

For clarity, my goal is to encourage developers who require stateful
connections to use HTTPS, and to make it more difficult to persist data
outside of a secure context.

With that in mind, I'm not enthusiastic about creating long-lived
mechanisms to deal with hybrid sites that try to span both HTTP and HTTPS
connections. This proposal (in combination with +Steven Bingler
<>'s schemeful same-site proposal
<>) suggests that `` and `` are not actually the same
site, and shouldn't be privileged with regard to each other. That seems
like the right place to land, and I'd like to ensure that the changes we
make to the platform lead in that direction towards a future in which:

1.  HTTP sites have, at most, session-based cookies as per the heuristics
described above
2.  HTTPS sites have persistent cookies.
3.  Never the twain shall meet.

Ideally, the load-balancing case devolves to the LB doing an immediate
redirect to HTTPS, and then deciding which backend the user should stick to
in that secure context. I don't think we should add new attributes in order
to support sites that push users back and forth from HTTPS to HTTP.