Re: [http-state] Welcome to http-state

"Adam Barth" <> Mon, 12 January 2009 23:08 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id D9FC53A67EA; Mon, 12 Jan 2009 15:08:55 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA47E3A67EA for <>; Mon, 12 Jan 2009 15:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RzYqJqic-ar1 for <>; Mon, 12 Jan 2009 15:08:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A4C3A3A67C0 for <>; Mon, 12 Jan 2009 15:08:53 -0800 (PST)
Received: by ewy10 with SMTP id 10so11779266ewy.13 for <>; Mon, 12 Jan 2009 15:08:37 -0800 (PST)
Received: by with SMTP id h10mr34797146ebc.39.1231801717374; Mon, 12 Jan 2009 15:08:37 -0800 (PST)
Received: by with HTTP; Mon, 12 Jan 2009 15:08:37 -0800 (PST)
Message-ID: <>
Date: Mon, 12 Jan 2009 15:08:37 -0800
From: Adam Barth <>
To: Discuss HTTP State Management Mechanism <>
In-Reply-To: <120206B6A348CA498C70E738A2E963514C0CD5@Nexus.cisecurity.lan>
MIME-Version: 1.0
Content-Disposition: inline
References: <> <120206B6A348CA498C70E738A2E963514C0CCC@Nexus.cisecurity.lan> <> <120206B6A348CA498C70E738A2E963514C0CD2@Nexus.cisecurity.lan> <> <120206B6A348CA498C70E738A2E963514C0CD5@Nexus.cisecurity.lan>
X-Google-Sender-Auth: c813f0e55c082502
Subject: Re: [http-state] Welcome to http-state
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Discuss HTTP State Management Mechanism <>
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Mon, Jan 12, 2009 at 2:58 PM, Blake Frantz <> wrote:

(out of order)

> For the purpose of this
> group, I think we may have identified another bullet item in the list of
> things to accomplish - figure out the best way to protect the integrity
> of Secure cookies.

I'm not an expert on what is or is not in scope for this working
group, but I think its important to protect the integrity of Secure
cookies.  Most people fall out of their chair when they realize Secure
cookies lack integrity.

(Further comments for those interested in the details of this discussion.)

> If the user agent treated two otherwise equal cookies from disparate
> schemes distinctly then the attacker must control content in the HTTPS
> scheme to impact the integrity of the Secure cookie.

While technically true, this doesn't actually help in practice because
Secure and non-Secure cookies are serialized identically in the Cookie
header, make it impossible for the server to tell whether the cookie
was set over HTTP or HTTPS.

> Nice work. In support of this, it *may* be beneficial to modify existing
> XHR mechanisms such that they prevent the programmatic creation of a
> Cookie-Integrity header (
> I haven't thought through this entirely, though.

XHR has a generic generic namespace of headers that can't be set by
script: those that begin with "Sec-".  We could simple name the header
"Sec-Cookie-Integrity" if we want this behavior.

>> 1) It is backwards compatible with existing servers who might
>> legitimately overwrite Secure cookies over HTTPS (for example, during
>> "logout").
> The cross scheme clobber prevention I'm attempting to get feedback on
> does not break this use case.

Oops.  Typo.  I meant "overwrite Secure cookies over HTTP (for
example, during logout)."  We could gather data how often this occurs,
but I suspect many sites that use both HTTP and HTTPS store auth
credentials in a Secure cookie, which they delete with an HTTP request
upon logout.

http-state mailing list