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.