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

"Yngve N. Pettersen (Developer Opera Software ASA)" <> Tue, 13 January 2009 00:22 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id DB9B63A67C0; Mon, 12 Jan 2009 16:22:17 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7B593A67C0 for <>; Mon, 12 Jan 2009 16:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.932
X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4sfeIlRZz8WI for <>; Mon, 12 Jan 2009 16:22:16 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9D9553A67AD for <>; Mon, 12 Jan 2009 16:22:14 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id n0D0Lv5Y023871 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for <>; Tue, 13 Jan 2009 00:21:57 GMT
Date: Tue, 13 Jan 2009 01:21:53 +0100
To: Discuss HTTP State Management Mechanism <>
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <>
Organization: Opera Software AS
MIME-Version: 1.0
References: <> <120206B6A348CA498C70E738A2E963514C0CCC@Nexus.cisecurity.lan> <> <120206B6A348CA498C70E738A2E963514C0CD2@Nexus.cisecurity.lan> <> <> <120206B6A348CA498C70E738A2E963514C0CDC@Nexus.cisecurity.lan>
Message-ID: <>
In-Reply-To: <120206B6A348CA498C70E738A2E963514C0CDC@Nexus.cisecurity.lan>
User-Agent: Opera Mail/9.26 (Win32)
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-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-15"; Format="flowed"; DelSp="yes"

On Tue, 13 Jan 2009 00:43:55 +0100, Blake Frantz <>  

>> Please note that RFC2965 already have such integrity checking through
> the
>> $Domain, $Path and $Port attributes.
> It's my understanding that these attributes are used to determine where
> the user agent should send the cookie to,

Not just that.

Clients are also required by RFC 2965 to send $Domain, $Path and $Port to  
the server for each cookie whenever the associated Domain, Path and Port  
parameters were used in the Set-Cookie2 header so that the server can pick  
the right one when multiple cookies have the same name.

My point about $Port is that if the server used either 'Port=' or  
'Port="443"' and checks for the $Port whenever the cookie is received, it  
will be able to detect if an unsecure server clobbered it, because that  
server would either have to use 'Port="80,443"', or not use Port at all,  
to be able to set the cookie and to get the cookie sent to the secure  
server. The receiving server will not be able to detect if a compromised  
secure server clobbered the cookie, but the $Origin field I am suggesting  
should handle that as long as the receiving server itself hasn't been  

Yngve N. Pettersen
Senior Developer                     Email:
Opera Software ASA         
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
http-state mailing list