[cabfpub] EV Wildcards

Ryan Sleevi sleevi at google.com
Thu Mar 19 23:31:58 UTC 2015


On Thu, Mar 19, 2015 at 4:20 PM, Eddy Nigg <eddy_nigg at startcom.org> wrote:

>  Thanks again Jeremy!
>
> I would like to state the following fact as food for thought on this
> subject....
>
> 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).
>

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.

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
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)
2) The image load be permitted
  2.a) Should the UI continue to show EV
  2.b) Should the UI be degraded to show DV
  2.c) Should the UI be degraded to show that a mixed content load has
occurred (e.g. as images are today)

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)

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)

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


[1]
https://w3c.github.io/webappsec/specs/mixedcontent/#category-optionally-blockable
[2] https://wiki.mozilla.org/IDN_Display_Algorithm , although Gerv may have
a more up to date document to reference
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150319/bf4f4c3f/attachment-0003.html>


More information about the Public mailing list