Re: report on EV and SSL MITM proxying

On 8 Mar 2011, at 03:59, peter williams wrote:

> Why did we attach EV type UI topics to the  issue in question?
>  
> We did NOT really have too much interest in EV per se. We were more interested in the browser UI (of which EV had some impact, recently, in the browsers of a few vendors, in some of their rendered pages).
>  
> Some folks suggested that life would be all rosy, in webland, if the browser displayed which client cert had been presented to a given website (per tab, presumably). How come those over-complicating security designer types, just don’t do simple and obvious things, when its ALL so EASY if one just thinks minimally and logically!

I have not seen an argument in what you have put forward that shows that this is not an easy thing to do. The only arguments from browser vendors I have heard, is that client certs are not widely used, and so it has not been a priority for them.

>  
> Well, it’s because life is not logical ; its crypto political – being a social space.

There are many issues of course. One of them may just be that client certs that can be only used on one site are not much more useful that SSL + password. So few people use this. WebID changes the dynamics as client certs can then be used with any site.

Let's focus on the easy issues to solve, without trying to work out what the crypto-political space is.

>  
> From that UI topic, I introduced slowly that what appears to be the case on the web, is not always the case (the whole SSL MITM issue). Ryan, your language style in one message drove the point home far better than a 100 messages did, from me. We then got onto the semantics of the padlock,

The padlock clearly was a mistake. No browser uses that anymore as I understand.

> the EV green’iness thing, the intended semantics of EV (that its better than mere server certs, in the spoofing area, where foaf cards being spoofed is an open issue, here).

EV gives more identity assurance. Not much, but useful it seems.

> We also touched briefly on the notions of SSL duplication (when a tab is duplicated before a refresh, and all the hypermedia document’s SSL connections state move over to the new tab, awaiting a refresh or link which runs new KDF-grade handshakes on the SSL connections operating of the shared or new TCP connections.) And, in general we started to ALL get a intuition of the nature of https as a system – as it actually operates in SSL MITMs, reverse proxy firewalls, CONNECT proxies on outbound channels, etc.

Only if a certificate can be placed in the browser. That's the nature of cryptology. If you are using your company's computer and did not re-install the OS, or allowed them to install software for you, then you partly are owned by them. 

( That's partly why languages such as Java, which provide a security logic in the software, are in the end very important for security, as they allow software to be downloaded and run in sandboxes. Otherwise you are forced to use VMs)

>  This allowed us to glimpse what it is about the world of websso (that institutionalized STS/proxies acting FOR the browser, or the RP site) that is different to https with its hidden proxies.
>  
> Since the goal is to use https, it seemed useful to really understand it, in its various planes.
>  
> We are about 60% of the way Id say. Folks are increasingly comfy with SSL, and are now understanding https in the hypermedia world. Folks have learned that SSL and SSL ciphersuites has nothing to say about certs, PKI, or https proxies.

yes, though there seem to be a few solutions here that can be looked into, and that don't seem initally to be anything extreemly complicated. 

The simplest: For legit company firewalls have your employees use client certificates and the firewall tie that to your company identity. This works if the company can put their certificate on the users computers in the CA or EV collection of certs, which MS Windows I am sure has an easy automatable solution for.

So I don't see that there is a big problem here. Not one that these companies who pay a lot of money for these services and for the organisation of it involved can't solve easily.

This does not work in internet cafes. (Unless the CAs are corrupt)

Henry

>  
> Somehow, https with client authn has to made suitable for the RDF graph world accessible by machines (vs the HTML graph mostly viewed by humans). After all, THAT is the MISSION. We want the https “scheme” URI to work in a webby way, when interacting first to release just the _private_ attributes of publicly-named foaf card to an authorized recipient.
> From: Ryan Sleevi [mailto:ryan@sleevi.com] On Behalf Of Ryan Sleevi
> Sent: Monday, March 07, 2011 3:40 PM
> To: 'peter williams'; public-xg-webid@w3.org
> Subject: RE: report on EV and SSL MITM proxying
>  
> Peter,
>  
> I agree that a policy needs to be stated with regards to TLS inspection. In considering such a policy, it's worth noting that inspection in an organization may have more reasons than simply malware inspection; such as legal or contractual obligations regarding the exchange of encrypted traffic. Think legal, medical, and financial, where regulatory pressures are often exerted on what and how information flows, and the onus is on the organization to enforce them.
>  
> Because of this, I think it may also be useful to re-evaluate the use of TLS client authentication, and consider exploring possible alternatives methods of identification. That's not to say that this issue can't be addressed by policy, just that such a policy, whether explicitly not supporting inspection or requiring vendors to adopt WebID-specific modifications, may prevent a wider deployment. This, of course, may be perfectly acceptable, but as you note, it seems to be untenable for many other recent webby forms of authn.
>  
> Since you mentioned at length the topic of EV certificates, I've included some information below that may help clarify a bit. I'm not sure how the context of EV relates to the SSL client authn scenario, unless you were merely wanting to point out that SSL MITM breaks client authn and also breaks EV (for most browsers), along with various other aspects of SSL/TLS, such as hello extensions.
>  
> The criteria for a Certification Authority to issue an EV certificate is published by the CA/Browser Forum at [1]. The specification outlines the requirements of a CA to vet the information asserted in the certificate, as well as the obligations of user agents with respect to validating them (such as revocation checking via CRL or OCSP).
>  
> Regarding Chrome/Chromium, the list of fingerprints and EV policy OIDs is published at [2]. If a constructed and verified certificate chain terminates in a root whose fingerprint matches the entry, and which successfully asserts (throughout the chain) the associated policy OID, then the certificate is marked as EV. This is used for all platforms except OS X. On Windows, this means that EV display in Chrome/Chromium happens independent of any local system configuration. The OIDs in this list are vetted by Google for inclusion within Chromium. See http://crbug.com/55520 http://crbug.com/58437 or http://crbug.com/73399 to see three examples of how this vetting happens.
>  
> With Safari, and with Chrome/Chromium on OS X, this information is determined by system configuration, the source of which is published athttp://www.opensource.apple.com (for example, 10.6.6's list of EV certs is at [3]). Apple publishes their policies at [4].
>  
> Mozilla adopts a similar approach, detailed at https://wiki.mozilla.org/PSM:EV_Testing , with the list of EV policy OIDs and signatures that have been vetted by Mozilla in [5]. The policies for getting included in this list are detailed athttps://wiki.mozilla.org/CA:Root_Change_Process
>  
> Note that the EV policy makes no assurances with respect to the "safety" of a page, such as whether it contains malware. Rather, it only reflects the fact that the information asserted by the CA, contained within the certificate, has been vetted more stringently than say, a Domain-Validated certificate. It only speaks to the operator of the website's identity, not necessarily the content hosted therein. So EV does not in and of itself incentivize an organization to disable their inspection policies.
>  
> While much more can be said about EV, OV, and DV certificates and the market realities, I think that perhaps [6] says all that is needed to be said on the issue. As I mentioned before, I'm not quite sure how it relates to the WebID assurances. Regarding the firewall minting certificates on the fly (the transparent SSL proxy), such certificates will not appear as EV in Safari/Chrome/Chromium/Firefox, which collectively make up a non-trivial amount of browser market share. I'm not sure for IE, but my understanding was that, until Windows 7 at least, IE itself was the one maintaining the list of EV roots (similar to the above), meaning the same would also apply for IE, but I could be mistaken [7].
>  
> Hopefully this helps clear up some of the statements made regarding EV certificates, and provides more information for consideration.
>  
> [1] http://www.cabforum.org/documents.html
> [2] http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ev_root_ca_metadata.cc?revision=HEAD&view=markup
> [3] http://www.opensource.apple.com/source/security_certificates/security_certificates-39576/buildEVRoots
> [4] http://www.apple.com/certificateauthority/ca_program.html
> [5] http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsIdentityChecking.cpp
> [6] http://www.mail-archive.com/cryptography@metzdowd.com/msg09873.html
> [7] CERT_CHAIN_POLICY_EV as a chain verification policy for CertVerifyCertificateChainPolicy() is not listed as supported until Windows 7.
>  
>  
> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of peter williams
> Sent: Monday, March 07, 2011 5:23 PM
> To: public-xg-webid@w3.org
> Subject: report on EV and SSL MITM proxying
>  
> 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.
>  
>  

Social Web Architect
http://bblfish.net/