RE: report on EV and SSL MITM proxying

>From the links given

"Each Opera instance will regularly download a digitally-signed list
identifying the CA..."

Can you characterize who issues the digitally-signed list? Is it Opera? is
it the OEM vendor served by Opera? Does Opera govern how the OEM behaves on
this topic? Is the OEM fully independent and autonomous?

How does Opera validate/revoke the signature on the list used by PCs - that
defines which CAs/issuers are "proper" EV issuing sites?

FOAF+SSL *did* have the notion that third party CAs COULD issue certs with
webids; though it never addressed the impact that layer 7 SSL MITM behavior
at a CONNECT proxy would/should have on delivery of browser-release client
certs to proxied servers. However, FOAF+SSL had *no* (public) notion that
there is a list that defines which third party CAs defined validity. 

In the EV world is there one such list, multiple such lists? Are the lists
per browser? Do the lists change with browser releases? Who controls the
list? Who audits the issuer of the list etc.

Perhaps, most significantly, is the list in Opera browser in an (OEM) WII
device the same as the public Opera build for PCs? Does the WII vendor
decide who it wants in its root list, or EV list? Does the WII vendor for
example have the power to define which EV sites are "recognized"? 

General answers about industry practice sought, not detailed answers. The
questions are just topic hints. The goal is to understand the general web
control system behind the UI features. 

We started this issue on the hope that a common browser UI metaphor could be
defined, pertinent to webid. (Henry wants the current client cert(s) per tab
on display, somehow). But, this topic suffered natural creep - looking at
what modern current UI topics exist re (server) certs. (we looked at
padlock, at EV green bars, at desktop widgets.) From there, we got to look
at the control system behind EV, that defines when UI is in effect. 


-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Yngve Nysaeter Pettersen
Sent: Tuesday, March 08, 2011 9:58 AM
To: public-xg-webid@w3.org
Subject: Re: report on EV and SSL MITM proxying

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-trustc
enter-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 Monday, 21 March 2011 15:36:09 UTC