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

RE: report on EV and SSL MITM proxying

From: Ryan Sleevi <ryan-webid@sleevi.com>
Date: Mon, 7 Mar 2011 18:40:04 -0500
To: "'peter williams'" <home_pw@msn.com>, <public-xg-webid@w3.org>
Message-ID: <094b01cbdd20$fc8f41d0$f5adc570$@com>


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


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



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


[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



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




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


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.


Received on Monday, 7 March 2011 23:42:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 March 2011 23:42:58 GMT