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

"Blake Frantz" <> Mon, 12 January 2009 23:40 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 7224828C143; Mon, 12 Jan 2009 15:40:37 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 77B0628C143 for <>; Mon, 12 Jan 2009 15:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yFcet3uniXdI for <>; Mon, 12 Jan 2009 15:40:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A421428C13B for <>; Mon, 12 Jan 2009 15:40:35 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 12 Jan 2009 18:40:16 -0500
Message-ID: <120206B6A348CA498C70E738A2E963514C0CDB@Nexus.cisecurity.lan>
In-Reply-To: <>
Thread-Topic: [http-state] Welcome to http-state
Thread-Index: Acl1CrctfSCpdFWzSW+Twt3i4z2DNAAAIppA
References: <><120206B6A348CA498C70E738A2E963514C0CCC@Nexus.cisecurity.lan><><120206B6A348CA498C70E738A2E963514C0CD2@Nexus.cisecurity.lan><><120206B6A348CA498C70E738A2E963514C0CD5@Nexus.cisecurity.lan> <>
From: Blake Frantz <>
To: Discuss HTTP State Management Mechanism <>
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

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

I see what you're a saying. However, if the user-agent actively asserts
"the integrity of these cookies is preserved" or the server operates on
the assumption that the cookie it previously set over HTTPS did not get
overwritten via HTTP (much like servers currently assume the user-agent
implements the same-origin policy), the server is still in the same
position - it must trust what the user agent is telling it with respect
to cookie integrity. 

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

Good idea. 

> Oops.  Typo.  I meant "overwrite Secure cookies over HTTP (for
> example, during logout)." 

Ah, yes, I agree this use case would break. Though, I don't think I've
encountered many, if any, instances of this. That surely doesn't mean a
million of them don't exist :)

http-state mailing list