<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 19, 2015 at 4:20 PM, Eddy Nigg <span dir="ltr"><<a href="mailto:eddy_nigg@startcom.org" target="_blank">eddy_nigg@startcom.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Thanks again Jeremy!<br>
    <br>
    I would like to state the following fact as food for thought on this
    subject....<br>
    <br>
    Today one can secure a (main) site with an EV certificate and have
    all content of that site including frames and iframes secured with a
    regular SSL certificate including wild cards. Browsers have always
    allowed this with the notable exception of Opera that had at some
    point a configuration setting for an "All EV" requirement. So if you
    are on an EV site, this doesn't mean that your connection is really
    secured with EV - a lot of information can be still leaked to other
    parties that have not undergone an extended validation and that's
    usually not what you want (but you don't know usually).<br></div></blockquote><div><br></div><div>We briefly experimented with this in Chrome, but like many things specs say but haven't actually thought out, we quickly found it did not work for users. A large number of "benign" positives, but also a number of increasingly complicated behaviours that could not be rationally explained to users.</div><div><br></div><div>For example, on an EV site, if you load a page (all EV), it presents the UI. If you then do an image fetch for a resource on a DV site, is</div><div>1) The image load blocked (e.g. treat it as active mixed content, which images are not presently treated as [1], nor at the time were XMLHTTPRequests)</div><div>2) The image load be permitted</div><div>  2.a) Should the UI continue to show EV</div><div>  2.b) Should the UI be degraded to show DV</div><div>  2.c) Should the UI be degraded to show that a mixed content load has occurred (e.g. as images are today)</div><div><br></div><div>Further, you can do all sorts of hijinks with browsers today with respect to redirect chains or DV loads that allow a MITM to use a DV cert to compromise an EV page's security boundary (such as loading script into the EV page). And there are even more complications when one considers how persistent web storage technology works (the localStorage or IndexedDB APIs are canonical examples, but also elements such as cookies)</div><div><br></div><div>This is all part of why I continue to sing the refrain of EV not providing strong security benefits (... yet). It's also a topic that we've thought quite a long time about, and one which has been discussed quite actively in a variety of Web standardization spheres (these same concerns apply to other technologies, such as HTTP Strict Transport Security and HTTP Public Key Pinning, in more limited forms, as well as to enterprise provided roots or cases of malware like Superfish)</div><div><br></div><div>I realize this may be seen as an off-topic digression, but I think it's key to understanding why we're overall supportive of the effort to allow wildcards within EV certificates. The phishing mitigation of high-risk requests is defense in depth, but not something we view as critical. The mixed scripting mitigation is something that browsers and DNS registries (and registrars) already have to deal with, and have developed robust criteria to defend against all types of attacks in this space. [2].</div><div> </div><div><br></div><div>[1] <a href="https://w3c.github.io/webappsec/specs/mixedcontent/#category-optionally-blockable">https://w3c.github.io/webappsec/specs/mixedcontent/#category-optionally-blockable</a></div><div>[2] <a href="https://wiki.mozilla.org/IDN_Display_Algorithm">https://wiki.mozilla.org/IDN_Display_Algorithm</a> , although Gerv may have a more up to date document to reference</div></div></div></div>