Re: [http-state] Security considerations overview

David Morris <dwm@xpasc.com> Wed, 03 March 2010 00:04 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 0B88D28C1BF for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:04:46 -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=[AWL=0.000, 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 eYZYIpGoGF+8 for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:04:44 -0800 (PST)
Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id A904428C1AC for <http-state@ietf.org>; Tue, 2 Mar 2010 16:04:44 -0800 (PST)
Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 448C610184E for <http-state@ietf.org>; Tue, 2 Mar 2010 16:04:47 -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 iz6Ura3304L0; Tue, 02 Mar 2010 16:04:47 -0800
Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 1A35610184C for <http-state@ietf.org>; Tue, 2 Mar 2010 16:04:47 -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 o2304jkC030950 for <http-state@ietf.org>; Tue, 2 Mar 2010 16:04:45 -0800
Date: Tue, 2 Mar 2010 16:04:45 -0800 (PST)
From: David Morris <dwm@xpasc.com>
To: http-state <http-state@ietf.org>
In-Reply-To: <5c4444771003021539i2ed4ea44mf6b52970bc52385b@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1003021547340.21569@egate.xpasc.com>
References: <5c4444771003021103s422a65c3me96af57dfee58105@mail.gmail.com> <Pine.LNX.4.64.1003021139330.4097@egate.xpasc.com> <5c4444771003021205t78c18f73t78913ae6ff3c70b1@mail.gmail.com> <Pine.LNX.4.64.1003021337130.21569@egate.xpasc.com> <5c4444771003021354o70faccache31b8a0d28005aeb@mail.gmail.com> <5691356f1003021438t1487d6d0g39439a2bdc3543ce@mail.gmail.com> <5c4444771003021452g44538236ta855abcfe6d578da@mail.gmail.com> <Pine.LNX.4.64.1003021508100.21569@egate.xpasc.com> <5c4444771003021539i2ed4ea44mf6b52970bc52385b@mail.gmail.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="17445122-741963202-1267574685=:21569"
X-Propel-ID: iz6Ura3304L0
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: Wed, 03 Mar 2010 00:04:46 -0000


On Tue, 2 Mar 2010, Adam Barth wrote:

> On Tue, Mar 2, 2010 at 3:27 PM, David Morris <dwm@xpasc.com> wrote:
> > No. Network attacks that impact HTTPS in general should not be used
> > to claim that cookies, by default, are not secure. Network infrastructure
> > manipulation which would reveal totally HTTPS website cookie content would
> > also expose everything else about the HTTP based application to intercept,
> > manipulation, etc.
> 
> We're not talking about vulnerabilities in HTTPS or TLS.  We're
> talking about the default behavior of the cookie protocol itself,
> which does not provide confidentiality from network attackers.
> 
> > I still don't see the actual vulnerability, and haven't yet reviewed
> > the backing details, but I think that makes me the typical reader of
> > the summary. If what I read in the summary doesn't make sense, I'll
> > probably ignore the details.
> 
> The issue is quite simple:
> 
> 1) In an HTTPS response, the example.com server responds with
> "Set-Cookie: foo=bar".  By default (i.e., without the optional Secure
> attribute), this cookie does not have the secure-only-flag set.
> 2) The user agent makes a single HTTP request.

That case was excluded by my earlier restriction to all HTTP.

> 3) The network attacker spoofs an HTTP response that contains an HTTP
> redirect to http://example.com/.

Only applies if there is an HTTP server on the same host. And it requires
a vulnerable infrastructure at either end of the connection.

This also suggests some issues with HTTP redirect which have not been
discussed in my reading/listening. It potentially exposes more than
cookies to the sniffer of traffic.

> 4) The user agent follows the redirect and sends the cookie foo in the
> clear, where it can be observed by the attacker.
> 
> > Furthermore, I suspect these vulnerabilities depend on the specific
> > User-Agent implemenation.
> 
> No.  The vulnerability is in the design of the protocol.

No. I can build special purpose useragents which will never have these
vulnerabilities.

> 
> > The executive summary needs to provide an accurate description of
> > the issue. I'd try to suggest an alternate set of words, but I don't yet
> > understand the basis of the claim.
> 
> The issue is described in detail later in the section.
> 
> > The generic summary statement proposed below applies equally to anything
> > associated with HTTP. By default the content isn't secure. If that is what
> > you mean, than say something like:
> >   Cookies as a subset of the HTTP protocol share all of the security
> >   vulnerabilities of HTTP and in some cases may excerbate the
> >   issues because of the possible leakage of cookie content to
> >   unintended servers...
> 
> That summary is insufficiently harsh.  The cookie protocol has a
> number of design errors that impair its security far more than the
> rest of the HTTP protocol.

    Cookies as a subset of the HTTP protocol share all of the
    security vulnerabilities of HTTP and in some cases cookie
    design flaws may excerbate the issues because of the
    possible leakage of cookie content to unintended servers...

makes it stronger? or since this is a summary, perhaps stop with
"excerbate the issues"