RE: report on EV and SSL MITM proxying

I think we are about 60% understanding https.

 

We are understanding now that not only can the outgoing corporate firewall
be an attacker, so can any reverse proxy on the path. There may be n of
them. Each one is semantically-attacking the end-end user model of https,
just as each one has the  poisoning document caches. (This is the security
way of looking at the web architecture J )

 

Here are some of the things we yet need to understand.

 

Smartcards, and how browsers delegate to the smartcards cryptomodule, or
other PKCS#11 module acting as a cryptomodule

 

How smartcard infrastructure use bridging, when the browser is not even
running on the PC which merely present an rdp-window with access to the
local smartcard drive (another corporate practice). That rdp connection
itself uses https, which protects the smartcard acess bridging, which
protects a second https channel.

 

A browser like IE may not be what you think of IE. When IE activeX control
is framed in a custom container, the container can change its trust anchors,
validation callbacks, and behavior. This affects things like EV, since the
address bar MAY not (in that modified "browser") be presented on all modal
popups (defeating the green'iness semantics of the whole EV world).

 

On a popup, the client cert being asserted may be released to the
popup-making site by a full handshake (server selected), causing a DOS on
the foaf card site.

 

Lots more, involving SSL MITMers that use apply the user's signing key
(having access, given "corporate" boundary assumptions and "ownership" of
keying material (and people, in the US) in the corporate world)

 

 

 

 

 

From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Tuesday, March 08, 2011 12:03 AM
To: peter williams
Cc: public-xg-webid@w3.org
Subject: 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 <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
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
<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.

 

 

 

Social Web Architect
http://bblfish.net/