On Aug 13, 2012, at 12:21 PM, Collin Jackson wrote: > On Mon, Aug 13, 2012 at 10:58 AM, Hill, Brad <bh...@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 _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
