Re: Cookies and schemes.

Willy Tarreau <> Mon, 09 March 2020 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DB403A0F47 for <>; Mon, 9 Mar 2020 06:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vVYqC213tbDp for <>; Mon, 9 Mar 2020 06:04:27 -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 198BC3A0EC9 for <>; Mon, 9 Mar 2020 06:04:26 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jBI1r-0002Io-R4 for; Mon, 09 Mar 2020 13:01:08 +0000
Resent-Date: Mon, 09 Mar 2020 13:01: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 1jBI1c-0002Gu-Dz for; Mon, 09 Mar 2020 13:00:52 +0000
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1jBI1W-0005Ur-K2 for; Mon, 09 Mar 2020 13:00:52 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 029D0TKN015962; Mon, 9 Mar 2020 14:00:29 +0100
Date: Mon, 09 Mar 2020 14:00:29 +0100
From: Willy Tarreau <>
To: Mike West <>
Cc: HTTP Working Group <>,
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: 1jBI1W-0005Ur-K2 e829a563c2975bc9f18be1ce196955d2
Subject: Re: Cookies and schemes.
Archived-At: <>
X-Mailing-List: <> archive/latest/37424
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Mike,

On Mon, Mar 09, 2020 at 09:51:46AM +0100, Mike West wrote:
> Hey folks!
> We've known for quite some time that cookies' lack of respect for the
> scheme that created them was an unfortunate choice that means cookies can
> give only weak guarantees of confidentiality
> <>. We further know that
> long-lived non-secure cookies create real risks for users (pervasive
> monitoring, data safety, etc).
> Martin Thomson's is
> one take on an approach to mitigating these risks.
> is another. Neither took
> off when they were proposed, but they seem to me to be clearly good ideas,
> at least directionally. Given the state of the world today, and the
> significant migration from HTTP to HTTPS we've seen in the past few years,
> I'd like to try tilting at this particular windmill again:
> 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).
> 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.
> The explainer tries to work through each of those and their implications in
> a little more detail. I'd appreciate feedback, either here or in the GitHub
> repo. :)

What I'm seeing there sounds reasonable to me. The main use I know for
cookies in clear text is for server stickiness. These ones are exclusively
session cookies (no expiration date so that they're never stored). With
browsers now staying open forever, these ones are sometimes problematic
(i.e. many users sticking to a single server after a domino effect) and
I've found myself having to artificially implement timeouts in their
values to be able to ignore too old cookies.

If we would implement a limitation to the lifetime of a session cookie,
it would solve this but would create a new problem which is that sessions
would be limited in time, which is not the same as limiting the idle time
as you don't want to break a session being used. What we need is a way to
let the client inform the server that it'd rather refresh the cookie if
it really wants the client to continue to present it (this is what we do
in haproxy as the expiration time is provided in the value so that we can
decide to drop it or update it). Or instead of forcing a limited lifetime
on session cookies in cleartext, we could force a limited idle time, which
more closely matches the real problem (i.e. users not aware they're passing
such info).

Regarding the scheme, there is a use case for cookies passed from HTTP
to HTTPS which is also to ensure the user can stick to the same server
when switching to HTTPS. But given that it's just for a short transition
it could make sense to address it exactly like the other one above, as a
session cookie only and with a much shorter lifetime.

One point worth mentioning is that while there are tons of legacy applications
outthere making use of cookies, I tend to think that nowadays most of them
are placed behind reverse-proxies for various reasons including performance,
security, integration, support for newer protocols, and that most of the
remaining legitimate clear-text cookies are really used by infrastructure
components such as load balancers, which are usually kept reasonably up
to date and can be reconfigured to adapt to an evolving ecosystem. In
addition I'm not aware of any valid use case of stored cookies learned
over cleartext connections.

While typing this I'm thinking that most of the cookies I'm seeing in
requests don't come from servers themselves but are set from javascript
components. Maybe we could already have browsers ask for user's consent
before setting a cookie from JS on a cleartext page ? And maybe also
before sending a stored cookie on such a page ? That would be a nice
way to get sites to progressively apply some cleanups and remove part
or all of their useless trackers.

It would also make sense to enforce shorter names+values for cleartext
cookies: if a server stores a lot of info in a cleartext cookie, then
there definitely is a problem and most likely it's not by design but
rather a mistake. Keeping only up to 16 chars for the name and 16 for
the value looks quite enough for a servername and various deliberate
use cases (infrastructure paths).

Just my two cents,