Re: [websec] handling STS header field extendability

[Collin Jackson <[e-mail]>]

On Mon, Aug 13, 2012 at 2:20 PM, Hill, Brad <[e-mail]> wrote:
> I have an EV certificate for www.example.com.  On the main page, it includes the following tag:
>
>  <script src="https://scripts.example.com/myscript.js">
>
> Mallory is presumably much more likely to be able to obtain a DV certificate for scripts.example.com than an EV cert for www.example.com.  But Mallory can still use the DV certificate to attack the EV content at www.example.com by MITMing the fetch of myscript.js, which will be transcluded into the DOM.
>
> Or alternately, assume that Mallory gets a DV certificate for www.example.com 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 "www.example.com" using the DV certificate is the same origin as my "www.example.com" 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
certificate.

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

Collin