Re: [websec] handling STS header field extendability

[Paul Hoffman <[e-mail]>]

On Aug 13, 2012, at 12:21 PM, Collin Jackson wrote:

> On Mon, Aug 13, 2012 at 10:58 AM, Hill, Brad <[e-mail]> 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