- From: Yngve Nysaeter Pettersen <yngve@opera.com>
- Date: Tue, 08 Mar 2011 18:57:47 +0100
- To: public-xg-webid@w3.org
Hi, First off, information about how EV works in Opera can be found in the following articles, including some modifications to what was discussed in earlier articles: http://my.opera.com/yngve/blog/2008/04/08/new-in-kestrel-end-of-the-extended-validation-wait http://my.opera.com/rootstore/blog/2008/07/03/rootstore-newsletter Updates http://my.opera.com/yngve/blog/2008/05/23/lowering-the-ev-bar http://my.opera.com/rootstore/blog/2010/12/09/ev-enabled-startcom-and-trustcenter-updated-public-suffix-list-to-v1-3 Essentially, an EV enabled client looks for the presence of a specific Policy OID in the site certificate, filtered by similar OIDs in the issuer certificates. This OID (or OIDs, some CAs have several) is associated in the browser with the EV-enabled Root. In Opera, the list of OID and the certificates they are associated with is downloaded weekly from our online rootstore repository at https://certs.opera.com/ (warning to people not using Opera: you will get redirected off the server, that server is an Opera-exclusive zone). The OID file, as well as each item in the OID list are digitally signed, and the signatures are checked before the file is used, and before the OID are used during certificate verification. Opera also have several hardcoded checks before the EV classification is allowed to stick; one of them is that revocation information must be available for all non-Root certificates in the chain. Other browsers may be using different systems, but the general lines of how EV is implemented is as above. AFAIK Windows allows system administrators to add new Roots globally in their network, as well as to EV enable such Roots (and for the record, I am not at all fond of that system). AFAIK Chrome is now using NSS as SSL/TLS stack, and was in any case using their own list for EV designations even while they used other stacks. ---- Regarding what EV means, it does not mean, and have never been intended to mean anything about the trustworthiness (including absence of malware) of the website in question. *That* problem is inherently intractable, particularly for an encryption system. What it *is* about, is being assured about the identity of the site and that, through a number of extensive checks, the certificate was issued to the true owner of the website, and that there is sufficient information to locate the owner in case there is a problem (i.e. whom to sue). The security of the server is entirely up to the website administrator. However IMO an administrator that spends the cash and time to obtain an EV certificate, should also spend some resources on securing the server itself, as well as making sure any off-site resources are secure (one of my pet peeves in this area is the inclusion of third-party Javascript, especially non-EV analytics scripts, in secure sites; see <http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-all-ev>). ---- The ability for users (and system administrators) to add new Root to the rootstores of the client is inherent in the design of all browsers, because anything else would make usability difficult in environments where a non-browser provided Root is used extensively. Also, even if the possibility wasn't offered, not even hardcoding the certificates into the binary would prevent somebody from reverse-engineering the file-format or executable to add their own Roots, or to EV enabled them (and in the case of Open Source browsers it is even easier to do that). It is not so much that SSL MITM proxying is _allowed_ or _enabled_ by this system, as that it has been co-opted for the MITM proxying, and that the ability also follows directly from how PKI (which is meant to be a scalable system for peers that don't necessarily know each other in advance) works, and that in any case there is nothing we browsers can really do to prevent it, should the "adversary" be persistent enough. This will be true as long the user does not check all the details, or while there are no automatic mechanisms for the user to reveal the existence of the MITM (when the MITM is trusted by the client), and as long as the server and client does not have secure Out-Of-Band information about each others that allow them to verify each other over an untrusted connection (e.g. a client might know the hash of the real site certificate). Currently, the only "real" option to prevent MITM attacks is to use pre-shared secrets, essentially transporting the keys physically between the peers, which is not feasible for the scales we are working on (it works in small intimate networks and the military). ---- Finally, I don't think it is reasonable to claim that client certificates were "sacrificed" for a SSL MITM proxy capability. As mentioned above, the MITM ability follows from how PKI (one of the usual cornerstones of TLS) works, and the configuration capability can be made difficult but not impossible. OTOH the inability of TLS based end-to-end authentication to pass through MITM proxies is due to the very definition of how client certificates works in the TLS protocol, as they are end-to-end, and based on a secret known only to the client so the MITM cannot fake it (although if the origin server can be configured to trust the MITM CA, then this argument also fails). One can perhaps say that using client certificate is the best option to protect against MITM SSL attacks (or proxies), as long as you can trust the server's verification and your own client certificate key database, but then, that is what security always comes down to: Either trusting the endpoints and intermediates, or making sure they cannot interfere without detection, but you still have to draw a line somewhere beyond which you have to trust that there have been no compromise. On Mon, 07 Mar 2011 23:23:22 +0100, peter williams <home_pw@msn.com> wrote: > http://www.w3.org/2005/Incubator/webid/track/issues/28 > > > its very hard to get an official statement on when browsers do or do not > show the "green address bar" background - to indicate that the resource > server has presented an EV grade cert. It's as vague as https conformance > itself. > > > I've decided we are in a spin zone, and browser/platform folks are > somewhat > embarrassed to admit that the praxis of the web is such that EV > CA-certified > sites can be spoofed, by vendor community design. There is a duping > infrastructure in place, for both EV and lesser grade SSL server certs. > > > Duping and Spoof are harsh words to use (and that's why it's all a spin > zone). From what I can tell, in windows one can locally designate any CA > trust anchor as an EV source, and thus impact the display of green > address > bars in those browsers influenced by that local designation (this > includes > IE, and I don't know if it includes Chrome). This affects those > (windows-based) browsers talking to the local https/SSL MITM firewall, > which > dynamically mints (EV) server certs on the fly once received from the > upstream channel, signing them with the firewall's "site spoofing" key > for > consumption by the browser on the downstream channel. By policy, this > spoofing key can be "designated" an EV trust anchor. The user under the > control of browser beholden to this local designation cannot easily tell > from browser behaviour which https URI in the address bar are true EV > sources, or the local firewall. > > > At RSA conference (full of folks well versed in SSL and certs), I asked > some > folks to comment, off the record. The rational is worth considering - as > it > speaks to the viability of simple client cert authn, in https. > > > Folks would say things like: There were numerous "vendor" tradeoffs, > including malware and the social acceptance of digitalids (client certs). > Since the open web is full of malware, and few public digital-id > accepting > public sites exist, we chose to sacrifice the hardly-used client authn > feature (end-end authn), enabling firewalls to spy on web documents > source > to https site for malware as they wander by. We recognized that the > MITMing > meant that end-end client authn was compromised. > > > When I questioned that surely EV semantics meant that browsers might have > more assurance that malware would be absent from EV-quality sites (per > se, > since they are under "EV governance") and that, therefore, MITM > intermediation was not required for the presumed-absent malware, there > was > not much response beyond a shrug; and an reference to spin zones. > > >> From Microsoft folks, I got an off the record point to consider the >> design > of their TMG product. It allows the operator to choose to inform the user > (or not) of the interception, using non-browser mechanisms. Folks were > proud > that the vendor had at least delivered an option, for the "moral" choice. > > > I think we are in a 99% crypto political space on this issue set. There > is a > "social desire" to have the capability to spoof sites; and the browser > vendors in CAB are somewhat embarrassed at their connivance in making it > reality. From what I know, they don't actually have the slightest choice. > but don't want to admit that publicly, either. Ultimately, the ability > to do > client authn end-end was sacrificed, with probably explains why the > layer 7 > ws*/websso model for user authn got more attention (to make up the > deficit, > at the transport layer). > > > Not sure what more I can formally do on this issue, since it's just not a > technical topic. We do need a policy though. We might want to also code > into > the standard the praxis of webservers/firewalls "properly" spoofing foaf > card endpoints (and bringing the webid protocol into compliance with the > praxis of SSL). Or, it can go into an RFC-style "security section" - > which > characterizes the vulnerabilities. > > > -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ********************************************************************
Received on Tuesday, 8 March 2011 17:58:24 UTC