Re: Browser security warning

I generally agree with you. However, afaik, (and I don't really),
almost no https sessions result in the browser checking a CRL or
OCSP responder. Does anyone have any real data about that? (Esp.
on the Internet as opposed to within enterprise networks.)

Oddly enough, if certificate status checking is rare, then really
the self-signed approach is, in principle, better from the revocation
p-o-v. (When the self-signed cert changes, the browser notices, if
the bad actor hasn't re-directed the connection; with "proper" certs
and no status checking, the client can swap back and forth between
the actual site and one using the compromised private key and never
notice.)

But certs that chain up to a trusted-CA stored locally are
generally more reliable as to naming, since CAs generally do do
their job fairly well. (That's if the list of CA-certs in
the browser is secure of course.) And naming is way more important
than revocation here.

(At least I've not heard of any attacks in the wild that would have
been defeated by a CRL or OCSP check, maybe I'm wrong there though?)

S.


Doyle, Bill wrote:
>  
> 
> 
> I feel that a self signed cert is a trust between the user and the
> site. The self signed cert may not be able to make use of programmatic
> mechanisms that support trust of a CA issued cert like CRLs. Continued
> trust of a site that uses a self-signed cert places the burden of trust
> on the user.
> 
> Turning off security indicators (padlock - url color) is one way to
> remind the user to keep tabs on the site and to verify that trust
> should continue to be extended.
> 
> It may also generate more calls to the sites help desk and maybe the
> site will buy a CA cert because it is less of a hassle than continued
> use of a self signed cert. If this happens this raises the level of
> security for all involved.
> 
> I agree that self-signed certs should be viable, but because they may
> not be supported by programmatic mechanisms to revoke the cert they are
> not in the same category as a CA generated cert.
> 
> Bill D.
> wdoyle@mitre.org
> 
> 
> 
> 
> -----Original Message-----
> From: public-wsc-wg-request@w3.org
> [mailto:public-wsc-wg-request@w3.org] On Behalf Of Stephen Farrell
> Sent: Wednesday, December 27, 2006 12:21 PM
> To: Stuart E. Schechter
> Cc: public-wsc-wg@w3.org
> Subject: Re: Browser security warning
> 
> 
> 
> 
> Stuart E. Schechter wrote:
> 
>>    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.
> 
> I don't know of any evidence for that, but would be interested if there
> were some. (Technically, I could also quibble a bit with your
> statement,
> since we're discussing server-authentication, so I guess you meant an
> SSL-server cert above and HTTPS can also be used with D-H, without
> providing server authentication, though that doesn't get much use.)
> 
> (At least in the developed world,) the point is not the actual amount,
> but whether or not to increase the existing bias towards getting
> people to pay commercial CAs for certs or not. Commercial CAs have
> their purpose, but should not IMO be required in order to create a
> perception of security for HTTP traffic. Sometimes they are
> appropriate, sometimes they just add a burden that arguably could
> cause less use of SSL - if its too much hassle to turn it on.
> 
>  >  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 don't agree that self-signed certs are a problem and would really
> not like to see such browser behaviour encouraged.
> 
> The main point is that naively differentiating between a "secure"
> state (padlock) and an insecure one (no padlock) isn't very effective.
> I don't believe that changing from that binary approach to an N-ary
> one, where the N options map to TLS state-machine states will be any
> more effective. We need a subtler mix...
> 
> S.
> 
> 
>

Received on Wednesday, 27 December 2006 20:07:38 UTC