Re: report on EV and SSL MITM proxying

For starters, please read:


http://my.opera.com/rootstore/blog/2008/07/03/rootstore-newsletter
http://my.opera.com/yngve/blog/2008/04/08/new-in-kestrel-end-of-the-extended-validation-wait
http://my.opera.com/yngve/blog/2008/04/08/new-in-kestrel-faster-root-certificate-updates

Which provides an overview of the system.

The certificate repository files are signed by Opera, and the index and  
the EV activation files are downloaded once a week.


On Mon, 21 Mar 2011 16:35:37 +0100, peter williams <home_pw@msn.com> wrote:

>> From the links given
>
> "Each Opera instance will regularly download a digitally-signed list
> identifying the CA..."
>
> Can you characterize who issues the digitally-signed list? Is it Opera?  
> is
> it the OEM vendor served by Opera? Does Opera govern how the OEM behaves  
> on
> this topic? Is the OEM fully independent and autonomous?
>
> How does Opera validate/revoke the signature on the list used by PCs -  
> that
> defines which CAs/issuers are "proper" EV issuing sites?
>
> FOAF+SSL *did* have the notion that third party CAs COULD issue certs  
> with
> webids; though it never addressed the impact that layer 7 SSL MITM  
> behavior
> at a CONNECT proxy would/should have on delivery of browser-release  
> client
> certs to proxied servers. However, FOAF+SSL had *no* (public) notion that
> there is a list that defines which third party CAs defined validity.
>
> In the EV world is there one such list, multiple such lists? Are the  
> lists
> per browser? Do the lists change with browser releases? Who controls the
> list? Who audits the issuer of the list etc.
>
> Perhaps, most significantly, is the list in Opera browser in an (OEM) WII
> device the same as the public Opera build for PCs? Does the WII vendor
> decide who it wants in its root list, or EV list? Does the WII vendor for
> example have the power to define which EV sites are "recognized"?
>
> General answers about industry practice sought, not detailed answers. The
> questions are just topic hints. The goal is to understand the general web
> control system behind the UI features.
>
> We started this issue on the hope that a common browser UI metaphor  
> could be
> defined, pertinent to webid. (Henry wants the current client cert(s) per  
> tab
> on display, somehow). But, this topic suffered natural creep - looking at
> what modern current UI topics exist re (server) certs. (we looked at
> padlock, at EV green bars, at desktop widgets.) From there, we got to  
> look
> at the control system behind EV, that defines when UI is in effect.
>
>
> -----Original Message-----
> From: public-xg-webid-request@w3.org  
> [mailto:public-xg-webid-request@w3.org]
> On Behalf Of Yngve Nysaeter Pettersen
> Sent: Tuesday, March 08, 2011 9:58 AM
> To: public-xg-webid@w3.org
> Subject: Re: report on EV and SSL MITM proxying
>
> Hi,
>
> First off, information about how EV works in Opera can be found in the
> following articles, including some modifications to what was discussed in
> earlier articles:
>
> http://my.opera.com/yngve/blog/2008/04/08/new-in-kestrel-end-of-the-extended
> -validation-wait
>     http://my.opera.com/rootstore/blog/2008/07/03/rootstore-newsletter
>
>   Updates
>     http://my.opera.com/yngve/blog/2008/05/23/lowering-the-ev-bar
> http://my.opera.com/rootstore/blog/2010/12/09/ev-enabled-startcom-and-trustc
> enter-updated-public-suffix-list-to-v1-3
>
> Essentially, an EV enabled client looks for the presence of a specific
> Policy OID in the site certificate, filtered by similar OIDs in the  
> issuer
> certificates. This OID (or OIDs, some CAs have several) is associated in  
> the
> browser with the EV-enabled Root.
>
> In Opera, the list of OID and the certificates they are associated with  
> is
> downloaded weekly from our online rootstore repository at
> https://certs.opera.com/ (warning to people not using Opera: you will get
> redirected off the server, that server is an Opera-exclusive zone). The  
> OID
> file, as well as each item in the OID list are digitally signed, and the
> signatures are checked before the file is used, and before the OID are  
> used
> during certificate verification.
>
> Opera also have several hardcoded checks before the EV classification is
> allowed to stick; one of them is that revocation information must be
> available for all non-Root certificates in the chain.
>
> Other browsers may be using different systems, but the general lines of  
> how
> EV is implemented is as above. AFAIK Windows allows system  
> administrators to
> add new Roots globally in their network, as well as to EV enable such  
> Roots
> (and for the record, I am not at all fond of that system). AFAIK Chrome  
> is
> now using NSS as SSL/TLS stack, and was in any case using their own list  
> for
> EV designations even while they used other stacks.
>
> ----
>
> Regarding what EV means, it does not mean, and have never been intended  
> to
> mean anything about the trustworthiness (including absence of malware) of
> the website in question. *That* problem is inherently intractable,
> particularly for an encryption system. What it *is* about, is being  
> assured
> about the identity of the site and that, through a number of extensive
> checks, the certificate was issued to the true owner of the website, and
> that there is sufficient information to locate the owner in case there  
> is a
> problem (i.e. whom to sue).
>
> The security of the server is entirely up to the website administrator.
> However IMO an administrator that spends the cash and time to obtain an  
> EV
> certificate, should also spend some resources on securing the server  
> itself,
> as well as making sure any off-site resources are secure (one of my pet
> peeves in this area is the inclusion of third-party Javascript,  
> especially
> non-EV analytics scripts, in secure sites; see
> <http://my.opera.com/yngve/blog/2007/06/19/it-aint-ev-til-its-ev-all-ev>).
>
> ----
>
> The ability for users (and system administrators) to add new Root to the
> rootstores of the client is inherent in the design of all browsers,  
> because
> anything else would make usability difficult in environments where a
> non-browser provided Root is used extensively. Also, even if the  
> possibility
> wasn't offered, not even hardcoding the certificates into the binary  
> would
> prevent somebody from reverse-engineering the file-format or executable  
> to
> add their own Roots, or to EV enabled them (and in the case of Open  
> Source
> browsers it is even easier to do that).
>
> It is not so much that SSL MITM proxying is _allowed_ or _enabled_ by  
> this
> system, as that it has been co-opted for the MITM proxying, and that the
> ability also follows directly from how PKI (which is meant to be a  
> scalable
> system for peers that don't necessarily know each other in
> advance) works, and that in any case there is nothing we browsers can  
> really
> do to prevent it, should the "adversary" be persistent enough.
>
> This will be true as long the user does not check all the details, or  
> while
> there are no automatic mechanisms for the user to reveal the existence of
> the MITM (when the MITM is trusted by the client), and as long as the  
> server
> and client does not have secure Out-Of-Band information about each others
> that allow them to verify each other over an untrusted connection (e.g. a
> client might know the hash of the real site certificate). Currently, the
> only "real" option to prevent MITM attacks is to use pre-shared secrets,
> essentially transporting the keys physically between the peers, which is  
> not
> feasible for the scales we are working on (it works in small intimate
> networks and the military).
>
> ----
>
> Finally, I don't think it is reasonable to claim that client certificates
> were "sacrificed" for a SSL MITM proxy capability. As mentioned above,  
> the
> MITM ability follows from how PKI (one of the usual cornerstones of TLS)
> works, and the configuration capability can be made difficult but not
> impossible. OTOH the inability of TLS based end-to-end authentication to
> pass through MITM proxies is due to the very definition of how client
> certificates works in the TLS protocol, as they are end-to-end, and  
> based on
> a secret known only to the client so the MITM cannot fake it (although if
> the origin server can be configured to trust the MITM CA, then this  
> argument
> also fails).
>
> One can perhaps say that using client certificate is the best option to
> protect against MITM SSL attacks (or proxies), as long as you can trust  
> the
> server's verification and your own client certificate key database, but
> then, that is what security always comes down to: Either trusting the
> endpoints and intermediates, or making sure they cannot interfere without
> detection, but you still have to draw a line somewhere beyond which you  
> have
> to trust that there have been no compromise.
>
>
>
>
> On Mon, 07 Mar 2011 23:23:22 +0100, peter williams <home_pw@msn.com>  
> wrote:
>
>> 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.
>>
>>
>>
>
>


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

Received on Monday, 21 March 2011 15:49:21 UTC