RE: report on EV and SSL MITM proxying

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!

 

Well, it's because life is not logical ; its crypto political - being a
social space.

 

>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 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). 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.

 

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. 

 

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 at
http://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 at
https://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
<http://src.chromium.org/viewvc/chrome/trunk/src/net/base/ev_root_ca_metadat
a.cc?revision=HEAD&view=markup> &view=markup

[3]
http://www.opensource.apple.com/source/security_certificates/security_certif
icates-39576/buildEVRoots

[4] http://www.apple.com/certificateauthority/ca_program.html

[5]
http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsIde
ntityChecking.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.