Re: [websec] handling STS header field extendability

Collin Jackson <collin.jackson@sv.cmu.edu> Mon, 13 August 2012 21:09 UTC

Return-Path: <collin.jackson@west.cmu.edu>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B3121F865E for <websec@ietfa.amsl.com>; Mon, 13 Aug 2012 14:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.866
X-Spam-Level:
X-Spam-Status: No, score=-2.866 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPI0nfBDanLO for <websec@ietfa.amsl.com>; Mon, 13 Aug 2012 14:09:47 -0700 (PDT)
Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA99F21F8650 for <websec@ietf.org>; Mon, 13 Aug 2012 14:09:46 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so3886882ghb.31 for <websec@ietf.org>; Mon, 13 Aug 2012 14:09:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=fTHvW0PRGdEEbjYwxzA6ncTVTRvOInE6bYZ78beLlc8=; b=nCrNsNzmeYIY4+q7Dlpqr3pGjQWj171QyUZqe/f8Qk5ZoHZTMrxBcXvWIvsi8S70Lf ytNCodlSxXdyvmOkMkZETYuvnabrzqseQhk2H5UE2jfKIVH7KNOUP7OxPF0BfUw887MM 7Tt0cMGQWqeL0Cr3DMHU1YkRJBYyOG0xaqavO70xoXfsAU2r+bbyfWuw1twMZ/q3FWys le6VP0tCM1KpwdJg0v26NIzTmMnI9nLAhOJQBJSj4haTvB2kUMT964NsfWmIcQhD7ijQ x1eWemB92KXSLu9yN0gcmqKX0jUU2SwG2hdZzmS0i2VnxFDoxqdksLHoB5CX+CAmgioV p/bg==
Received: by 10.236.78.3 with SMTP id f3mr12553492yhe.34.1344892186509; Mon, 13 Aug 2012 14:09:46 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id l1sm1148581yhm.19.2012.08.13.14.09.46 (version=SSLv3 cipher=OTHER); Mon, 13 Aug 2012 14:09:46 -0700 (PDT)
Received: by yhq56 with SMTP id 56so4066722yhq.31 for <websec@ietf.org>; Mon, 13 Aug 2012 14:09:45 -0700 (PDT)
Received: by 10.66.74.67 with SMTP id r3mr18674398pav.1.1344892185348; Mon, 13 Aug 2012 14:09:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.21.131 with HTTP; Mon, 13 Aug 2012 14:09:05 -0700 (PDT)
In-Reply-To: <FD1D3117-B393-417A-868F-AB954907C16C@vpnc.org>
References: <5024352D.4040604@KingsMountain.com> <CAOuvq23dxoKyV2No55WEYePhVj+Fcab5cF65C1FsiqgtmEkXMA@mail.gmail.com> <CA+cU71kx4Ck2aMeSHhnpb--aZ+mRmszQdojepM4aapVn2TsR=Q@mail.gmail.com> <370C9BEB4DD6154FA963E2F79ADC6F2E1C251C@DEN-EXDDA-S12.corp.ebay.com> <CANVv-VfcVBhd7AUqsZ83dKJiDL3V=_Fd2Wmm=o7WXMiEgCAusg@mail.gmail.com> <FD1D3117-B393-417A-868F-AB954907C16C@vpnc.org>
From: Collin Jackson <collin.jackson@sv.cmu.edu>
Date: Mon, 13 Aug 2012 14:09:05 -0700
Message-ID: <CANVv-VcEwGR3TyvJDSDxb9Y141-GSozAJtMBSFwDh9O6Oz_RTA@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnaOdLJXymrRRhBuz4lPF7LyfbBQPpAwUCJwoT/nxS3qpr+RwBYoBS6bw3nB8WxJpEFGOBu
Cc: Ben Campbell <ben@nostrum.com>, IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] handling STS header field extendability
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2012 21:09:47 -0000

I don't understand your question, but I'll attempt to rephrase my comment.

Brad was describing a network attacker that was able to obtain a DV
certificate (but not an EV certificate) for a target site. The
attacker can "act as a partial MITM and provide, using a DV
certificate, trojan script content in an iframe with no security
indicators or substitute an external script in a legitimate page and
that script will have full access to content delivered with an EV
certificate." This would allow, for example, the attacker to read
cookies and passwords entered into a bank's login form.

My point is that if the site is using LockEV, the network attacker's
DV certificate is useless, so LockEV is useful even if the browser's
script access checks don't pay attention to the EV/DV distinction.

On Mon, Aug 13, 2012 at 2:00 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> On Aug 13, 2012, at 12:21 PM, Collin Jackson wrote:
>
>> On Mon, Aug 13, 2012 at 10:58 AM, Hill, Brad <bhill@paypal-inc.com> wrote:
>>> There are, of course, non-browser HTTP clients that may respect HSTS, but EV certificates in particular are aimed at a browser audience as it is about user trust indicators.
>>>
>>> EV is *not* a security boundary in browsers, however.  It is a brand awareness and consumer trust product.
>>>
>>> I am not aware of any user agents that treat EV and non-EV content as having different effective security principals for purposes of the Same Origin Policy.  So, although it is more difficult to get an EV certificate than a DV one, that does not provide any effective security against a MITM attacker who can obtain a DV certificate.  Such an attacker can always act as a partial MITM and provide, using a DV certificate, trojan script content in an iframe with no security indicators or substitute an external script in a legitimate page and that script will have full access to content delivered with an EV certificate.
>>>
>>> I would posit that means a feature like LockEV has little to no practical value unless and until (not likely) Web user agents provide origin isolation between EV and non-EV content.
>>
>> Quite the opposite, you just made the argument in favor of LockEV. If
>> LockEV is being used, the MITM attack with a DV certificate would no
>> longer be possible, because the DV certificate would not be accepted
>> by the browser.
>
> In what case is that attack useful? The public key would still be the one that the site thought they had an EV cert for.
>
> Confused...
>
> --Paul Hoffman