Re: [http-state] Security considerations overview

David Morris <dwm@xpasc.com> Tue, 02 March 2010 23:27 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 DD85B3A89A4 for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 15:27:32 -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 sAIdfVukm1n5 for <http-state@core3.amsl.com>; Tue, 2 Mar 2010 15:27:32 -0800 (PST)
Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id E43DD3A887A for <http-state@ietf.org>; Tue, 2 Mar 2010 15:27:31 -0800 (PST)
Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 59CA510183D for <http-state@ietf.org>; Tue, 2 Mar 2010 15:27:34 -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 iz6Ura32nry0; Tue, 02 Mar 2010 15:27:34 -0800
Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 3A6DA100586 for <http-state@ietf.org>; Tue, 2 Mar 2010 15:27:34 -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 o22NRWmY029315 for <http-state@ietf.org>; Tue, 2 Mar 2010 15:27:32 -0800
Date: Tue, 2 Mar 2010 15:27:32 -0800 (PST)
From: David Morris <dwm@xpasc.com>
To: http-state <http-state@ietf.org>
In-Reply-To: <5c4444771003021452g44538236ta855abcfe6d578da@mail.gmail.com>
Message-ID: <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>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="17445122-1249067625-1267572452=:21569"
X-Propel-ID: iz6Ura32nry0
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 23:27:33 -0000

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. 

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.

Furthermore, I suspect these vulnerabilities depend on the specific
User-Agent implemenation. 

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

David Morris


On Tue, 2 Mar 2010, Adam Barth wrote:

> On Tue, Mar 2, 2010 at 2:38 PM, Tyler Close <tyler.close@gmail.com> wrote:
> > On Tue, Mar 2, 2010 at 1:54 PM, Adam Barth <ietf@adambarth.com> wrote:
> >> On Tue, Mar 2, 2010 at 1:46 PM, David Morris <dwm@xpasc.com> wrote:
> >>> 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.
> >>
> >> Even if your whole application is HTTPS-based, the cookies are
> >> vulnerabile to active network attackers.  That is a true statement,
> >> and precisely the security problem we're trying to point out in that
> >> sentence.  Maybe this is a better formulation?
> >>
> >> [[
> >>        In addition, by default,
> >>        the cookie protocol does not provide confidentiality from network
> >>        attackers.
> >> ]]
> >
> > A reader could again misinterpret that formulation and so believe the
> > problem can be fixed by using HTTPS, which is incorrect.
> >
> > I think this thread is a good indication that providing an "executive
> > summary" at the start of the Security section could be very effective
> > in communicating the rationale behind the prior recommendation against
> > using cookies in new applications. Succinct statements can sometimes
> > communicate better than detailed descriptions.
> 
> Does this help?
> 
> [[
>         In addition, by default,
>         the cookie protocol does not provide confidentiality from network
>         attackers, even when used over HTTPS.
> ]]
> 
> Adam
> _______________________________________________
> http-state mailing list
> http-state@ietf.org
> https://www.ietf.org/mailman/listinfo/http-state
>