Re: [websec] handling STS header field extendability

"Hill, Brad" <> Mon, 13 August 2012 21:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA8FA21F84B3 for <>; Mon, 13 Aug 2012 14:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.117
X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 056Tl3MCFdAE for <>; Mon, 13 Aug 2012 14:21:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E4DD721F84A0 for <>; Mon, 13 Aug 2012 14:21:04 -0700 (PDT)
DomainKey-Signature: s=ppinc;; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=MW/1BtIFwxRasd3rDmVRmaXKgRRz73d4VdfOkY3aoCgGrZXuDDAspiO7 JnV8VyfJjn2oOhxLfTb5fxlge6Q3zaqzWfLm9IPx9cgAPSaZszW6VclNf UeEbQAn2Hob6RuA;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=ppinc; t=1344892865; x=1376428865; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zfiIxbPDSRk/NLw6Qw88wmM3/eqTnhshQUo081sisHQ=; b=UY8r2OVyGDIHv3dk6n8ASPDu+HeWe7NZAmxE6qTYTfb8DiZWDDry25nD M3Ye0ZB1P9CQYHqQsB6zKHU1lpgii6aZl68DVypJPHp6xpa+nBUo1Tm1t hMfR8PSj9otLUjr;
X-EBay-Corp: Yes
X-IronPort-AV: E=Sophos;i="4.77,762,1336374000"; d="scan'208,217";a="9146511"
Received: from (HELO ([]) by with ESMTP; 13 Aug 2012 14:21:04 -0700
Received: from ([fe80::40c1:9cf7:d21e:46c]) by ([fe80::5c45:283f:1e47:5cdf%17]) with mapi id 14.02.0298.004; Mon, 13 Aug 2012 15:20:21 -0600
From: "Hill, Brad" <>
To: Paul Hoffman <>, Collin Jackson <>
Thread-Topic: [websec] handling STS header field extendability
Thread-Index: AQHNdnu9G2/cgF2QOE2DrHCPRwkn4JdT/HaAgAEaOQCAAvRWEIAAfk+AgAAbqYD//53BMA==
Date: Mon, 13 Aug 2012 21:20:20 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A==
x-ems-stamp: zn7wKYpsPqCW7ONKLuM9bQ==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter: Scanned
Cc: Ben Campbell <>, IETF WebSec WG <>
Subject: Re: [websec] handling STS header field extendability
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Aug 2012 21:21:05 -0000

I have an EV certificate for  On the main page, it includes the following tag:

 <script src="">

Mallory is presumably much more likely to be able to obtain a DV certificate for than an EV cert for  But Mallory can still use the DV certificate to attack the EV content at by MITMing the fetch of myscript.js, which will be transcluded into the DOM.  

Or alternately, assume that Mallory gets a DV certificate for which is different (and has a different key pair) from my legitimate EV certificate.  Mallory can still MITM content loaded in some frame other than the one displaying the EV indicator and gain control of that content because her "" using the DV certificate is the same origin as my "" using the EV one.

So, Collin is right that perhaps I'm making the case *for* LockEV, but as my first example shows, it would have to include a full-fledged mixed-content distinction between EV and non-EV, as currently exists between HTTPS and HTTP.

When you start to consider more modern technologies for intercommunication between multiple instances of client-side apps with things like postMessage, webRTC, etc. I wonder if you wouldn't need a full-fledged origin distinction on EV/non-EV, as we do today on protocol, to create a strong barrier, and if it is worth it and there is any appetite among browser vendors for such a thing.


> -----Original Message-----
> From: Paul Hoffman []
> Sent: Monday, August 13, 2012 2:01 PM
> To: Collin Jackson
> Cc: Hill, Brad; Ben Campbell; IETF WebSec WG
> Subject: Re: [websec] handling STS header field extendability
> On Aug 13, 2012, at 12:21 PM, Collin Jackson wrote:
> > On Mon, Aug 13, 2012 at 10:58 AM, Hill, Brad <>
> 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