Re: Cookies and schemes.

Willy Tarreau <> Tue, 10 March 2020 03:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C58B3A0EB9 for <>; Mon, 9 Mar 2020 20:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4fpF5UyFlLRb for <>; Mon, 9 Mar 2020 20:43:26 -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 94C693A0EB7 for <>; Mon, 9 Mar 2020 20:43:26 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jBVkk-00031M-0U for; Tue, 10 Mar 2020 03:40:22 +0000
Resent-Date: Tue, 10 Mar 2020 03:40:22 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jBVke-00030b-2h for; Tue, 10 Mar 2020 03:40:16 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1jBVkb-0000Jj-VE for; Tue, 10 Mar 2020 03:40:15 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 02A3dvjw017997; Tue, 10 Mar 2020 04:39:57 +0100
Date: Tue, 10 Mar 2020 04:39:57 +0100
From: Willy Tarreau <>
To: Martin Thomson <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1jBVkb-0000Jj-VE d6d645719ef68d560c9df3430b2942d0
Subject: Re: Cookies and schemes.
Archived-At: <>
X-Mailing-List: <> archive/latest/37429
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Tue, Mar 10, 2020 at 09:02:25AM +1100, 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://

Maybe that can work.

>  The Sec-Nonsecure-Cookie header field seems like it might not be great long term.

I don't believe in adding attributes to legacy applications anyway. If they
rely on older mechanisms it's because they cannot be changed, and it's not
by changing default behavior that we'll make them suddenly capable of adapting
their code to emit new cookie attributes.

> Tf the goal is to support temporally-constrained transfer, then binding the
> cookies to the redirect avoids pulling from previous state.  Also, the
> redirector could have just packed this information into the target URL, so
> it's not a new tracking vector.


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

  1) client connects over HTTP to
  2) the load balancer doesn't find a cookie, applies the load balancing
     algorithm and forwards the request to server #1
  3) server responds, load balancer appends cookie "SERVER=srv01" to the
  4) client makes a few more HTTP requests presenting "SERVER=srv01",
     which the LB spots and continues to pass to server #1. Since the
     client presents the cookie, the LB doesn't append it on new responses.
  5) one such response is now a 302, client then sends a request over
     HTTPS, still presenting the cookie "SERVER=srv01". The load balancer
     sees it and forwards it to the server and doesn't append it on response.

Past this point, if the client stops presenting the cookie, we'll lose the
binding. I'm still not clear on how to address this without systematically
appending a cookie to responses, which is bad. We're exactly in the situation
where I was thinking that it would be nice to have the ability for the client
to signal the server "I'm going to expire this cookie, please renew it if
still needed".

Maybe the right approach would be to change the default behavior with a
new attribute. Currently without any attribute the cookie is presented
to both schemes, while with the secure attribute it's presented only to
HTTPS. By having an explicit such as "secure-and-insecure" or something
like this, we could have load balancers explicitly set this one for
server affinity, and let the client present it to both HTTP and HTTPS.
Then with this, we could stop presenting an HTTP-learned cookie over
HTTPS at all by default.

Just my two cents,