Re: [http-state] Security considerations overview

David Morris <dwm@xpasc.com> Tue, 02 March 2010 21:46 UTC

Return-Path: <dwm@xpasc.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9225628C1F6 for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 13:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AklPICcOQW1R for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 13:46:12 -0800 (PST)
Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id C27FD28C182 for <http-state@ietf.org>; Tue, 2 Mar 2010 13:46:12 -0800 (PST)
Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 8C7B410184B for <http-state@ietf.org>; Tue, 2 Mar 2010 13:46:14 -0800 (PST)
X-Propel-Return-Path: <dwm@xpasc.com>
Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.1.9347 $Rev: 9262 $) id iz6Ura32lKe0; Tue, 02 Mar 2010 13:46:14 -0800
Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 6CEF4101842 for <http-state@ietf.org>; Tue, 2 Mar 2010 13:46:14 -0800 (PST)
Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id o22Lk9rR022169 for <http-state@ietf.org>; Tue, 2 Mar 2010 13:46:13 -0800
Date: Tue, 02 Mar 2010 13:46:09 -0800
From: David Morris <dwm@xpasc.com>
To: http-state <http-state@ietf.org>
In-Reply-To: <5c4444771003021205t78c18f73t78913ae6ff3c70b1@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1003021337130.21569@egate.xpasc.com>
References: <5c4444771003021103s422a65c3me96af57dfee58105@mail.gmail.com> <Pine.LNX.4.64.1003021139330.4097@egate.xpasc.com> <5c4444771003021205t78c18f73t78913ae6ff3c70b1@mail.gmail.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="17445122-280844096-1267566369=:21569"
X-Propel-ID: iz6Ura32lKe0
Subject: Re: [http-state] Security considerations overview
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: http-state <http-state@ietf.org>
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Mar 2010 21:46:13 -0000


On Tue, 2 Mar 2010, Adam Barth wrote:

> On Tue, Mar 2, 2010 at 11:42 AM, David Morris <dwm@xpasc.com> wrote:
> > On Tue, 2 Mar 2010, Adam Barth wrote:
> >>         <t>Transport-layer encryption, such as HTTPS, is insufficient to
> >>         prevent a network attacker from altering a victim's cookies because
> >>         the cookie protocol does not provide integrity.  By default, cookies
> >>         are transmitted in the clear, where their confidentiality can be
> >>         compromised by a network attacker.</t>
> >
> > I don't under stand how the second sentence extends the thought in the
> > first sentence. It seems in conflict in the sense that HTTPS is not
> > sending cookies in the clear and use of HTTPS is generally recommended
> > as the way to avoid compromise by network hackers. What am I missing?
> 
> If even if you use the cookie protocol exclusively over HTTPS, the
> default is still to send the cookies in the clear (i.e., the
> secure-only-flag defaults to false).

But wrapped inside of the HTTPS stream, it is like the remainder of
everything about the HTTP request (including headers), sans any general
HTTPS vulnerabilities, not visible on the network to hackers. 

If you are trying to say that a cookie sent on an HTTPS connection from
a server will be returned on any non-HTTPS connections and hence be
vulnerable in that context, the paragraph doesn't say that. To me it
says that even if my WHOLE application is HTTPS based, the cookies
are vulnerable on the network.