Re: [websec] handling STS header field extendability

Collin Jackson <> Mon, 13 August 2012 23:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E945121F859B for <>; Mon, 13 Aug 2012 16:21:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.894
X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xkJ4MQrBqB2f for <>; Mon, 13 Aug 2012 16:21:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3B1EB21F8592 for <>; Mon, 13 Aug 2012 16:21:38 -0700 (PDT)
Received: by yenm5 with SMTP id m5so4199442yen.31 for <>; Mon, 13 Aug 2012 16:21:37 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=DEFYGvBRP8rJaux9OCeGGBIDufQX4PvQfNCWM8ZK3q8=; b=ZRaRPLbKFN2eUWF3aN+UHHhZtZ0uIgsYbkb3vpOsFctH+wjUbzuGkR7uVfbDM+YpUf 3MchWWg1u5HhISUayhRs7jLeGNusgEhS1m4IAp7kILHmVCVtnBvEmpPjGXecfa3b1Uf6 X83H7OB4G8Bn5dxAjoOvoGuDLDNVrSJiX97AFwoSQ+ol8QhU2qRfZnrZ9lU8gr3joIGP 9IMJyaqWQkS82G5CSrv+laJkr5UI48mi2Fz6IcT4W/Xwduhpo/WNlLW+4z8eF9iizsty PPh48e0Ru7hKS1NL/fcE2VMARBi8gVJC9flRG9Od9ZJNcPd3xsPROBVikVEq+eh5D7RE EWHg==
Received: by with SMTP id t40mr4014771ann.77.1344900097577; Mon, 13 Aug 2012 16:21:37 -0700 (PDT)
Received: from ( []) by with ESMTPS id e24sm1755334yhh.4.2012. (version=SSLv3 cipher=OTHER); Mon, 13 Aug 2012 16:21:37 -0700 (PDT)
Received: by yhq56 with SMTP id 56so4206371yhq.31 for <>; Mon, 13 Aug 2012 16:21:36 -0700 (PDT)
Received: by with SMTP id uk4mr35012903pbc.52.1344900096112; Mon, 13 Aug 2012 16:21:36 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 13 Aug 2012 16:20:55 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Collin Jackson <>
Date: Mon, 13 Aug 2012 16:20:55 -0700
Message-ID: <>
To: "Hill, Brad" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQklk26OTko2M6AN1MM0PbfjQVFTYeFREMjfPlo/n1x+73gbS/uS83fUPX37X6pNDf65hxTl
Cc: Ben Campbell <>, IETF WebSec WG <>, Paul Hoffman <>
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 23:21:39 -0000

On Mon, Aug 13, 2012 at 2:20 PM, Hill, Brad <> wrote:
> 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.

I don't agree that browsers would need to include a mixed content
distinction between EV and non EV. In fact, I think that would be a
bad idea to do so. You can still make an all-EV site and benefit from
LockEV. The attacker will not be able to MITM it without an EV

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

As we wrote in our 2008 paper on finer-grained origins, I agree that
browsers should not include EV in the origin distinction. However,
LockEV would still be helpful to all-EV sites.

> Again: instead of "LockEV", wouldn't a much saner security policy be "LockKey"?

Sites might want to commit to serving everything over EV, but might
not want to commit to keeping the same key, or the same CA.

> I think that's important to consider about LockEV - PayPal is one of the sites most ready for and most pervasively EV, and it would not be prepared today to have a mixed-content policy enforced for EV/DV.  It would take a lot of work and a great deal of expense to achieve this, and not just for PayPal.  Consider how many sites use off-origin analytics, ads, CDNs, etc.

We agree. I am opposed to using EV in the mixed content distinction.
However, LockEV still prevents MITM attacks using DV certificates
against all-EV sites.

> I'm not convinced that:
> a) it's worth doing LockEV unless it's going to be a real security barrier

As long as a site isn't using DV certs for scripts, it's a real
security barrier.

> b) the complexity introduced in making it a real security barrier is worth it for such a rare attack

There is very little complexity introduced if you don't introduce the
mixed content distinction.