Re: [http-state] Security considerations overview

Adam Barth <ietf@adambarth.com> Wed, 03 March 2010 00:15 UTC

Return-Path: <ietf@adambarth.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 306FC28C133 for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:15:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 zTafP64wD8SO for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 16:15:47 -0800 (PST)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 015F13A8CC0 for <http-state@ietf.org>; Tue, 2 Mar 2010 16:15:46 -0800 (PST)
Received: by gwb10 with SMTP id 10so515990gwb.31 for <http-state@ietf.org>; Tue, 02 Mar 2010 16:15:44 -0800 (PST)
Received: by 10.101.133.35 with SMTP id k35mr285167ann.50.1267575344123; Tue, 02 Mar 2010 16:15:44 -0800 (PST)
Received: from mail-iw0-f179.google.com (mail-iw0-f179.google.com [209.85.223.179]) by mx.google.com with ESMTPS id 21sm4585525iwn.7.2010.03.02.16.15.43 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Mar 2010 16:15:43 -0800 (PST)
Received: by iwn9 with SMTP id 9so917293iwn.17 for <http-state@ietf.org>; Tue, 02 Mar 2010 16:15:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.156.205 with SMTP id y13mr70127ibw.27.1267575342170; Tue, 02 Mar 2010 16:15:42 -0800 (PST)
In-Reply-To: <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> <Pine.LNX.4.64.1003021547340.21569@egate.xpasc.com>
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 2 Mar 2010 16:15:22 -0800
Message-ID: <5c4444771003021615s1fad680eldcf70157b23ac237@mail.gmail.com>
To: http-state <http-state@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [http-state] Security considerations overview
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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:15:48 -0000

On Tue, Mar 2, 2010 at 4:04 PM, David Morris <dwm@xpasc.com> wrote:
> 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.

Even if a web server operates exclusively over HTTPS, general purpose
user agents are willing to issue HTTP requests.

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

We're discussing a network attacker.  A network attacker can spoof an
HTTP response from a host even if that host is not operating an HTTP
server.  Likewise, a network attacker can intercept an HTTP request to
a host even if that host is not operating an HTTP server.

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

What issues with HTTP redirects do you mean?  That's how HTTP
redirects work according to the HTTP specification.

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

We're talking about the protocols as specified.  You can profile HTTP
and the cookie protocol to make them more secure, but that's not how
they work out-of-the-box.

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

I don't think we should be mealy mouthed here.  The protocol is not
well-designed for security.  We should be clear so that folks aren't
confused into creating vulnerable servers.

Adam