Re: [websec] handling STS header field extendability

["Hill, Brad" <[e-mail]>]

tl;dr version:

EV is not a security boundary today in web user agents, it is a way to get a user interface decoration.

If we want to ask browser vendors to make it into a security boundary which they will defend, we need to think about a fairly complex and broad threat model.

I'm not convinced that:

a) it's worth doing LockEV unless it's going to be a real security barrier
b) the complexity introduced in making it a real security barrier is worth it for such a rare attack

-Brad

> -----Original Message-----
> From: Hill, Brad
> Sent: Monday, August 13, 2012 2:20 PM
> To: 'Paul Hoffman'; Collin Jackson
> Cc: Ben Campbell; IETF WebSec WG
> Subject: RE: [websec] handling STS header field extendability
> 
> 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.
> 
> 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.
> 
> -Brad
> 
> > -----Original Message-----
> > From: Paul Hoffman [mailto:[e-mail]]
> > 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 <[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