RE: report on EV and SSL MITM proxying

WE don't really care about EV here, we care about "learning from EV" and its
UI struggles -  to see the impact on webid client certs and web documents
that the web architecture wants to cache (widely). The summary points that I
feel are pertinent to webid work are:

Concerning padlocks (vs green address bars): "If a certificate chain fails
either CRL or OCSP ver[i]fication (but is not revoked) the associated
website will not get a padlock indication, and the security toolbar will not
be displayed." This UI concept seems to be distinguishing padlock and
address bar semantics, based on the differences between non-availability of
revocation info and info stating cert is revoked/suspended. There are 4
states: green/not-green, padlock/no-padlock. I still cannot tell how this
works, PER TAB, or PER-INSTANCE of the browser. It's the padlock the
lowest-common denominator of all tabs EV/revocation state?

Concerning mashups (the heart of semantic web), we see something VERY
interesting: "And lastly, if the Web site includes content from other Web
servers, those servers must *also* be hosting EV-sites. This is a point at
which we are much stricter than the other EV-capable browsers currently. As
I said earlier: "It ain't EV 'til it is EV, all EV". I think this means that
the UI changes color/padlock depending upon the DOM document enforcer in the
browser reporting that each link also points to a site with an EV cert. If
the XHTML/RDFa document/graph changes (to now include a site with no EV
cert), the browser behaves differently between the 2 moments. Different
browsers implement different "document/graph semantics", per se, in any
case. For example, open IE9 on XHTML+RDFa at time t on the site s,  it may
report EV-good; open Opera v.latest with the same conditions, it may report
EV-bad (due its "enhanced" graph-semantics for https).

I also noted caching related changes to OCSP. This allows a proxy to cache a
validation response (since the browser is no longer enforcing OCSP nonces,
or SSL nonces as a precondition of cert validity). If that proxy is the
system proxy on a PC, should the internet connection be removed, the
revocation information can be "still available" to the browser (being
cached). Being "available" means the data exists in a proxy - whose cache is
trusted by the browser, using web caching semantics (not OCSP or SSL
semantics). 

Is this fair?

Webid is about W3C-style webbiness, not IETF-style security. Via the UI
analysis angle (on EV), we seem to have to go to some core webby topics: 

1. security state change based on cert's original issuing criteria
2. security state change based on availability of revocation/status info
3. security state changes based on the references in a graph 

I think it all comes down to this:

If I have a foaf card in XHTML/RDFa (with my self-asserted pubkey) hosted on
an EV-site, and I (10s later) add the wrong party (pointing to the webid of
a person whose site has NO EV cert), my own site in Opera now no longer
shows the green-address bar when rendering my foaf card in XTHML+RDFa. (10s
ago, it did.)






-----Original Message-----
From: Yngve Nysaeter Pettersen [mailto:yngve@opera.com] 
Sent: Monday, March 21, 2011 8:49 AM
To: public-xg-webid@w3.org; peter williams
Subject: Re: report on EV and SSL MITM proxying


For starters, please read:


http://my.opera.com/rootstore/blog/2008/07/03/rootstore-newsletter
http://my.opera.com/yngve/blog/2008/04/08/new-in-kestrel-end-of-the-extended
-validation-wait
http://my.opera.com/yngve/blog/2008/04/08/new-in-kestrel-faster-root-certifi
cate-updates

Which provides an overview of the system.

The certificate repository files are signed by Opera, and the index and the
EV activation files are downloaded once a week.


On Mon, 21 Mar 2011 16:35:37 +0100, peter williams <home_pw@msn.com> wrote:

>> 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-ex
> tended
> -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 16:51:40 UTC