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 16:06:10 -0400
Message-ID: <46929532.7040203@cs.cmu.edu>
To: michael.mccormick@wellsfargo.com
CC: stephen.farrell@cs.tcd.ie, wdoyle@mitre.org, tlr@w3.org, public-wsc-wg@w3.org, Pete.Palmer@wellsfargo.com, conflongspeak@wellsfargo.com



michael.mccormick@wellsfargo.com wrote:
> A self-signed cert requires no vetting by a TTP so it is inherently at
> least a little riskier.  Obviously the actually degree of vetting
> depends on the CA and the class of cert, but some is better than none.
> Also there's a liability dimension to consider.  If I'm defrauded by
> someone who obtained a TLS cert improperly, the CA who issued the cert
> may owe me compensation or at least be suable.  I have no such recourse
> with a SSC; hence more risk.

The cheaper SSL certificates also require little vetting by a CA.  They 
confirm you own the domain, and that's it.  They don't vouch for 
business practices or anything else related to intent.  With an SSC, you 
also show some control over the site, as you need to modify the web 
server.  It's silly arguing this, we've already seen plenty of phishing 
sites that use legitimately issued low-grade certificates.

Sure, if you're defrauded you might try going after the CA, but good 
luck.  For low-grade certificates, CAs make it perfectly clear that they 
only vouch for domain ownership.  As it stands it's up to the user to 
determine how the certificate is issued.  How many users understand what 
a certificate even is, much less a CA?

> 
> Expired certificates aren't just a revenue stream for VeriSign et al.
> They're also a mechanism for regularly retiring credentials more quickly
> than they would typically be compromised by entropy or attack (same
> reason we expire passwords) and for forcing recertification & re-vetting
> of the requester.  The presence of an expired TLS cert may indicate the
> holder was unable to obtain a replacement, or has used the credential
> for far longer than its entropy period.  Either way there's risk.

Sure, I agree.  But look at the *likelihood* of the risk.  Of all the 
sites on the Internet with an expired certificate, how many are being 
exploited?  It's a very small fraction.  There's always a risk, but if 
the risk is ridiculously small and you're much more likely to fall 
victim another way, we shouldn't waste our time.  There's a greater risk 
that the site will be compromised another way, than because someone was 
able to brute force the private key.

And again, the recertification is a joke for low grade certificates.  If 
getting a low grade cert is all it takes to get the A-OK from the 
browser, that's what fraudulent sites will use.

> 
> Revoked certificates are obviously high risk.  I think a "can't find
> status information" cert has to be treated the same as a revoked cert
> from a risk perspective.

I agree in principle, as I said before.  However, how many sites use 
certificates where revocation information could not be found?  Of those, 
how many have actually been revoked?  I'm sure there's someone on this 
list who might be able to get that information...

> 
> Average end users don't need to know about this stuff or even what
> certificates are.  But they do need to know that a security condition
> has been detected which raises the risk of using a site for high-trust
> activities.

Sure, I agree, and that's why we're arguing about this.  We need to 
determine which scenarios are actually high risk (and I don't just mean 
what someone has to lose, but also what the likelihood of the risk is).

But this is all moot anyway.  If a user is intent on submitting 
information to a website, he or she will rarely look for the presence of 
an SSL indicator.  Even when they do notice them, most users will submit 
information anyway.  Hypothetically, if we can create effective warnings 
for all these scenarios, chances are that fraudulent sites would simply 
not use SSL.

serge
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] 
> Sent: Monday, July 09, 2007 12:53 PM
> To: Serge Egelman
> Cc: McCormick, Mike; wdoyle@mitre.org; tlr@w3.org; public-wsc-wg@w3.org
> Subject: Re: ACTION-240 :TLS errors...
> 
> 
> 
> 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.
> 
>  > 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.)
> 
>  > 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.
> 
> 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 20:07:45 GMT

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