Re: [http-state] Security considerations overview

Adam Barth <ietf@adambarth.com> Tue, 02 March 2010 23:39 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 6CE163A8ABE for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 15:39:38 -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 rzSJb-IJZthU for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 15:39:37 -0800 (PST)
Received: from mail-yx0-f188.google.com (mail-yx0-f188.google.com [209.85.210.188]) by core3.amsl.com (Postfix) with ESMTP id 820383A7A68 for <http-state@ietf.org>; Tue, 2 Mar 2010 15:39:37 -0800 (PST)
Received: by yxe26 with SMTP id 26so460123yxe.29 for <http-state@ietf.org>; Tue, 02 Mar 2010 15:39:34 -0800 (PST)
Received: by 10.150.213.19 with SMTP id l19mr305379ybg.90.1267573174630; Tue, 02 Mar 2010 15:39:34 -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 22sm4536874iwn.8.2010.03.02.15.39.33 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Mar 2010 15:39:33 -0800 (PST)
Received: by iwn9 with SMTP id 9so884826iwn.17 for <http-state@ietf.org>; Tue, 02 Mar 2010 15:39:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.160.205 with SMTP id o13mr342450ibx.13.1267573173089; Tue, 02 Mar 2010 15:39:33 -0800 (PST)
In-Reply-To: <Pine.LNX.4.64.1003021508100.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>
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 2 Mar 2010 15:39:13 -0800
Message-ID: <5c4444771003021539i2ed4ea44mf6b52970bc52385b@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: Tue, 02 Mar 2010 23:39:38 -0000

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.
3) The network attacker spoofs an HTTP response that contains an HTTP
redirect to http://example.com/.
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.

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

Adam