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

Re: ACTION-240 :TLS errors...

From: Serge Egelman <egelman@cs.cmu.edu>
Date: Mon, 09 Jul 2007 15:24:39 -0400
Message-ID: <46928B77.5040305@cs.cmu.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
CC: michael.mccormick@wellsfargo.com, wdoyle@mitre.org, tlr@w3.org, public-wsc-wg@w3.org



Stephen Farrell wrote:
> 
> 
> 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.  
> 
> Not really. I can scale an attack involving newly crafted SSCs as
> large as I like, but one that requires a $20 spend per different
> cert is more difficult. So "as secure" isn't strictly correct.

Let's forget the cost for a second.  The point is, if we make an 
effective indicator that warns about SSCs, fraudulent sites will simply 
start shelling out a marginal amount of money in order to get legitimate 
certificates.  Of course, this assumes that this indicator is effective. 
  But then again, if we're going to advocate for an ineffective 
indicator, what's the point of recommending anything in this area at all?

> 
>  > Now, what about expired
>> certificates?  Can anyone really argue that an expired certificate is 
>> riskier than a self-signed one?  
> 
> I wouldn't argue that. However, an expired cert is arguably riskier than
> a valid cert. (We're dealing with a partial order here at best.)

What about real world data?  I'm not saying this doesn't happen, but 
based on the number of sites with expired certificates, I would wager 
that most are just that--expired, and of all the sites out there with 
expired certificates, there's a very small fraction that are either 
compromised or outright fraudulent.  This becomes a value judgment: if 
we make an effective indicator to warn about sites with expired 
certificates, the ones that are genuinely fraudulent will shell out the 
money for a current certificate.  The net result will be that visitors 
to websites where the webmaster is lazy will encounter this warning when 
there's probabilistically just as much danger as visiting a site with a 
valid SSL certificate.

The problem we need to really think about is habituation.  There is 
countless literature in ergonomics and warning science about repeated 
exposure to similar looking warnings.  If users see warnings for every 
conceivable SSL error, they will ignore all such warnings.  Instead we 
need to narrow down the threats that are most serious and only show 
warnings when those come up, so that they appear as infrequently as 
possible.

> 
>  > I would argue that most of the current
>> SSL-related warning messages have little impact on the user's 
>> security.   The only current browser error with regard to certificates 
>> that should actually be meaningful is if a certificate has been revoked.
> 
> How is "revoked" sensibly treated any different from "can't find
> certificate status information"? If it can't really be treated
> differently then there's a nice slippery slope that ends up
> presenting everything to do with PKI back to the user, which of
> course none of us want.

Sorry, I forgot yet another SSL warning.  You're right, revoked really 
isn't too different from "no information available."  But based on real 
world data, I would assume that of the ones where no information is 
available, a small fraction of them have actually been revoked.  Again, 
value judgment: if we treat them the same way, the sites that are 
actively being used for fraud will just get new certificates.

serge

> 
> So overall, I'd argue that no PKI stuff should be exposed at all,
> (modulo not knowing what I really think is best for SSCs;-)
> 
> S.

-- 
/*
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 19:26:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:49 GMT