W3C home > Mailing lists > Public > public-xg-webid@w3.org > March 2011

Re: report on EV and SSL MITM proxying

From: Yngve Nysaeter Pettersen <yngve@opera.com>
Date: Tue, 08 Mar 2011 18:57:47 +0100
To: public-xg-webid@w3.org
Message-ID: <op.vr1dilz5vqd7e2@killashandra.oslo.osa>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 March 2011 17:58:25 GMT