Re: Browser security warning

MIT Lincoln Laboratory.  I was added to the project about a week ago.  I'm
interested in the project because I've been involved in security usability
studies of browser indicators.  I'm also active in the security economics
community.  I think there are some interesting incentive issues here.

   I can imagine four reasons why a site might rely on self-signed certs

  (1) The service is being tested and is not yet ready for deployment
  (2) The administrator hasn't got the $20 to get a low-end CA cert.
  (3) The administrator is only concerned about eavesdropping and
     so believes a self-signed certificate is adequate.
        (In reality, if an attacker can eavesdrop (s)he can probably
        forge packets as well.)
  (4) The administrator doesn't have the time/skills to install a
      CA cert and figures that users will click through to the page
      even if the cert is self signed.

   HTTPS servers in category 1 (testing) can be handled by having an
preference setting for advanced users that informs the browser to allow
certain self-signed certs (ideally, only when a hash of the cert is
entered).

   I don't think there is a large set of sites that can't afford a CA cert
(category 2) and actually require the security offered by HTTPS.

   The real problem here are sites in categories (3) and (4).  These sites
train users to accept self-signed certificates.  These cases are common
because administrators do not have a strong enough incentive to get and
install a CA-cert.

   If browsers continue to allow access to self-signed certificates via a
click-through warning, then sites in categories (3) and (4) will remain a
problem and we'll continue to train users that self-signed certs are
acceptable.

   I think the safest default behavior for a browser that receives a
self-signed cert is to show an error page.  The message should tell the user
to contact the site's administrator to ask them to fix the problem.

   I am concerned about the approach of rendering the page but hiding HTTPS
indicators.  In this approach, does the address bar contain http or https?
The former would be to imply that a redirect happened and to show it would
be to give the user a sense of security.

   Cheers

   Stuart


> Doyle, Bill wrote:
>> I like the point brought up in Mike's note.
>> 
>> "For sites with self-signed certs, I think there's growing support
>> for the idea of simply not showing any security indicators at all."
> 
> Seems a bit too simplistic to me (and a bit biased towards commercial
> CAs).
> 
> I think better would be to treat all SSL server certs that can't be
> verified the same. That might mean not displaying security indicators
> or it might mean displaying them, depending on other factors.
> 
> A scenario where displaying would be fine: I have my own web server
> that I installed and whose content I control. It should be ok for me
> to mark that self-signed cert (or hostname or whatever combination
> makes sense) as being ok to display as "secure". I would guess that
> that might generalise to a scenario about non-commercial community
> sites.
> 
> So generally, if a user has a way to mark a site as "ok" then
> successfully using the same self-signed cert is a fairly strong
> indicator that the site is still "ok" on subsequent visits and is
> certainly not the same as re-visiting that site via cleartext HTTP.
> 
> S.
> 
>> 
>> The trust between a user and a site with a self signed cert is a
>> private trust mechanism. In this situation 3rd parties are not involved
>> and cannot provide information to support a trust decision, should
>> turning off security indicators be promoted to a standard?
>> 
>> 
>> Bill D.
>> wdoyle@mitre.org
>> 
>> 
>> 
>> -----Original Message-----
>> From: public-wsc-wg-request@w3.org
>> [mailto:public-wsc-wg-request@w3.org]On Behalf Of Michael(tm) Smith
>> Sent: Friday, December 22, 2006 6:34 AM
>> To: public-wsc-wg@w3.org
>> Subject: Re: Browser security warning
>> 
>> 
>> 
>> michael.mccormick@wellsfargo.com, 2006-12-21 11:58 -0600:
>> 
>>> I just tried to access a reputable web site that issues its own
>>> SSL certs
>> 
>> How exactly did you make the determination that it's reputable?
>> (I'm not being facetious.) How could a user be expected to tell it
>> apart from a unreputable site that has a self-signed cert?
>> 
>> For sites with self-signed certs, I think there's growing support
>> for the idea of simply not showing any security indicators at all.
>> If we were to do that consistently across browsers, users would
>> never see any warning dialog at all for this case, nor any padlock
>> icon or anything else to indicate that the site has a cert.
>> 
>>> and got this warning message from IE6:
>>> "You are about to install a certificate from a CA claiming to
>>> represent www.x9.org.  Windows cannot validate that the
>>> certificate is actually from www.x9.org.  You should confirm its
>>> origin by contacting www.x9.org.  The following number will
>>> assist you in this process:
>>> Thumbprint (sha1): 8FBF6185 1D390508 F04BA0CB 31F4C4C E5310DAE.
>>> 
>>> "Installing a certificate with an unconfirmed thumbprint is a
>>> security risk.  If you click Yes you acknowledge this risk.  Do
>>> you want to install this certificate?"
>> 
>> I guess in part this is case of the application providing too much
>> information. Maybe the part that says "Windows cannot validate
>> that the certificate is actually from www.x9.org" is enough.
>> 
>> Here's what a few other browsers say for the same site:
>> 
>> -----------------------------------------------------------------
>> The root certificate for this server is not registered. You may
>> install this certificate. Accept/install?
>> 
>> - The root certificate from "www.x9.org" is not known to Opera.
>> Opera cannot decide if this certificate can be trusted.
>> -----------------------------------------------------------------
>> 
>> -----------------------------------------------------------------
>>   The server certificate failed the authenticity test.
>> 
>>   Certificate is self-signed and thus may not be trustworthy.
>>   ...
>> -----------------------------------------------------------------
>> 
>> -----------------------------------------------------------------
>>   Unable to verify the identity of www.x9.org as a trusted site.
>>   Possible reasons for this error:
>>   - Your browser does not recognize the Certificate Authority that
>>   issued the site's certificate.
>>   - The site's certificate is incomplete due to a server
>>   misconfiguration.
>>   - You are connected to a site pretending to be www.x9.org,
>>   possibly to obtain your confidential information.
>> 
>>   Please notify the site's webmaster about this problem.
>> 
>>   Before accepting this certificate, you should examine this
>>   site's certificate carefully. Are you willing to to accept this
>>   certificate for the purpose of identifying the Web site
>>   www.x9.org?
>> -----------------------------------------------------------------
>> 
>>> I'm a security professional and even I find this message very
>>> hard to understand and almost completely unactionable.  An
>>> ordinary user would ask:
>>> * What is a certificate?
>> [...]
>> 
>> It's going to be very hard for any browser to provide information
>> about the problem without mentioning the word "certificate".
>> 
>> How would you suggest the browser could make an ordinary user
>> understand what a certificate is so that the user can take action
>> when encountering this case (a site with a self-signed cert for
>> which no browser is going to have a root certificate)?
>> 
>> Or do you think browsers should not even bother trying to warn
>> users about sites with self-signed certs? (That is, just treat
>> them as they would an unsecure site without any cert.)
>> 
>>   --Mike
>> 
>

Received on Wednesday, 27 December 2006 16:47:20 UTC