W3C home > Mailing lists > Public > public-wsc-wg@w3.org > July 2007

Re: ACTION-240 :TLS errors...

From: Johnathan Nightingale <johnath@mozilla.com>
Date: Mon, 9 Jul 2007 15:47:55 -0400
Message-Id: <F299F3B3-5531-49BD-AF33-691DEAEE45D9@mozilla.com>
Cc: W3C WSC Public <public-wsc-wg@w3.org>
To: Serge Egelman <egelman@cs.cmu.edu>

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.

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.

> 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.

> 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.



Johnathan Nightingale
Human Shield
Received on Monday, 9 July 2007 19:48:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:14:17 UTC