Re: ACTION-240 :TLS errors...

Johnathan Nightingale wrote:
> 
> On 9-Jul-07, at 1:33 PM, Serge Egelman wrote:
> 
>> How is the risk that much greater for a self-signed certificate than a 
>> standard CA-signed one?  Since a certificate can be purchased for $20, 
>> a self-signed cert is effectively as secure.
> 
> Except that a $20 SSL cert from a trusted root still must prove domain 
> ownership.  Obviously this doesn't help against homograph attacks and 
> the like (although in practical terms, most of our trusted roots, even 
> the discount ones, do watch for homograph attacks on popular targets) 
> but that doesn't make it inconsequential.

What do we care about domain ownership when someone has full control of 
the web server?  To put up an SSC, you need to configure the server.

> 
> I can't speak for other browsers, but if there's a CA in our root store 
> whose certs are no more trustworthy than a self-signed cert, we should, 
> and would, pull their root.

Sure, pull all low grade certificates.  The problem here is some 
certificates are being used just for encryption, and others are being 
used to prove intent.  If we only care about encryption, we don't need 
to look at any roots.  If we're trying to use every certificate found to 
determine the intent of a website, we need to hold every certificate to 
the same standard.  Proving domain control does not prove intent.

> 
>> Now, what about expired certificates?  Can anyone really argue that an 
>> expired certificate is riskier than a self-signed one?
> 
> An expired cert is no more trustworthy than a SS cert, but may be 
> less-so, strangely enough.  CAs don't tend to keep revocation data for 
> expired certs, so an expired cert ought to be treated as revoked, from a 
> security-purity point of view (which is not to say that this is the most 
> usable approach.)  If expired certs are allowed to pass by unfettered, 
> it creates a pretty pleasing hole for attackers, by undermining the 
> revocation aspects of PKI.  Obviously, treating them as revoked will 
> tend to push the holders of expired certs towards renewal (if they are 
> legitimate) or SS-certs (if they are trying to hide from revocation).  
> This argues for making our treatment of SS-certs tougher.

Sure, that's a valid argument.  But we still know nothing about the 
self-signed certificate.  Are individuals issuing CRLs or implementing 
OCSP for their self-signed certificates?  Doubtful.  And again, are we 
talking about providing encryption or proving intent?  Neither of these 
say anything about intent.  But they do provide a level of encryption 
above sending everything in plain text.

> 
>> Most of the current errors can be eliminated.  I think the only one 
>> that we need to consider for most users is revocation.
> 
> What would your recommendation be for SS certs?  We toyed with the idea 
> of saying that an SS cert connection should be quietly encrypted, but 
> present no security indicators, since we have no reason to trust it.  
> The problem is that this enables the MitM scenario nicely.  A diligent 
> user is careful never to visit her bank except via her trusted https 
> bookmark, or by typing in the URL manually.  If someone tried to DNS 
> spoof with a straight http connection, the attempt would fail, since the 
> https connection would fall on the floor.  But if SS certs are quietly 
> allowed through, the attacker can spin a SS-cert for bankofamerica.com 
> and the connection would succeed (albeit without the usual context 
> indicators).  This is the kind of thing that can't happen with a cert 
> issued by a trusted CA, even a $20 one.
> 
> That scenario has led us towards considering a harsher attitude towards 
> bad certs in general.  There is discussion going on now (not final, of 
> course) around making SS-certs and other broken-cert conditions into 
> error pages, without a 1-click override.  Users can add certs to a list 
> of overrides for their intranet, etc., but it's a complicated procedure 
> and outside of their immediate task flow.  If we do this, it will make 
> people sad.  But it may also help to clean up some of the ubiquity of 
> self-signed certs out there on the public web, and it's not clear to us 
> how to make the process nicer without making the attack process nicer as 
> well.

Look at real world data.  What fraction of phishing attacks are due to 
DNS poisoning?  What fraction are due to users not looking at URLs or 
even understanding what a domain name is?  What fraction of data leaks 
come from hacked databases as compared to eavesdropping?  We're arguing 
about a very complicated solution to a problem that isn't very pervasive 
(relatively speaking).

Look at it from the other side: EV certs are the great panacea that 
solve these problems.  Yet most users do not notice the green address 
bar (much less the absence of it!).  From the study that I'm finishing 
up, not one user noticed the green address bar.  Not one user noticed 
that the phishing sites they visited did not use any SSL indicators. 
However, full screen warnings that interrupt the user's task were 
extremely effective.  I was under the impression that we had already 
consensus that training users to recognize the absence of an indicator 
is futile.

Ideally, certificates should be used for encryption, and that's about 
it.  If a site has a certificate that hasn't been revoked, we don't need 
to bother them.  Then we focus on detection of malicious sites and warn 
when we encounter them.  Constructing such warnings doesn't force us to 
train users to differentiate between chrome and content, another futile 
task, as there's no incentive to spoof them.

serge
> 
> Cheers,
> 
> J
> 
> ---
> Johnathan Nightingale
> Human Shield
> johnath@mozilla.com
> 
> 
> 

-- 
/*
PhD Candidate
Vice President for External Affairs, Graduate Student Assembly
Carnegie Mellon University

Legislative Concerns Chair
National Association of Graduate-Professional Students
*/

Received on Monday, 9 July 2007 20:26:39 UTC