Re: Browser security warning

On 26-Dec-06, at 2:57 PM, Stuart E. Schechter wrote:

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

There's another use case that isn't really captured here, due to the  
limitations of the commercial CA structure. For example, if I own the  
foo.com, and am not planning on using it for public purposes but want  
an SSL channel for various services like ftp.foo.com and www.foo.com  
and mail.foo.com and webdav.foo.com, I might want a *.foo.com  
certificate. That's far more expensive to purchase (note: expensive  
enough to be a reason why a lot of banks don't SSLify their front  
pages) and so I might just not bother since I can make my own.

SSL was never, AIUI, intended to be a "you must pay to play"  
situation. I think you're being a little unfair in use cases (2), (3)  
and (4) with your wording, and as someone else pointed out, leaning  
heavily towards commercial CAs as being the only solution.

That said, the common use case we can extract from these cases is one  
where the site administrator or owner has some sort of personal  
relationship with the expected end-user. They could be a user within  
a local enterprise, a friend, or a member of a community. But, what  
we can do, is expect that the administrator give the user some sort  
of instruction as to how they can view the site they are trying to view.

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

Here, I agree with you, though not with the causality. When a self- 
signed certificate is used on sites where the administrator has no  
relationship with the user, all they're doing is offering some sort  
of protection for eavesdropping. The warning is pretty meaningless to  
all but people who really know what's going on, and even then, it's  
of limited value.

>    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 think a self-signed certificate is an error, though. Not  
showing the content is making a pretty extreme assertion. You're  
basically saying "the only reason someone has a self-signed  
certificate here is to make you think that it's safe in an effort to  
fool you". That wasn't even enumerated in your use cases, and isn't  
the whole EV certificate initiative being kickstarted because  
phishers are easily able to get el-cheapo certificates anyway?

Let's isolate the problem:

What would the problem be in rendering https and other security  
signals for self-signed certs? Well, it's that someone might think  
the site is "secure". Why is that? Because some of them have been  
trained to read certain signals that actually mean "SSL connection"  
as "site is secure".

It sounds to me like this is all stemming from that problem, rather  
than the problem that some people are using self-signed certificates.  
If we had seperate UI signals for "secure" as opposed to "encrypted",  
and any trust that people would understand the difference (sigh),  
we'd be much better off!

One possibility would be to not render the page unless the user takes  
a deliberate action. One that I'd proposed to the NSS team and which  
they seemed to like a great deal was to have users go into the  
security dialog and explicitly add the URL of the site they hope to  
trust. The experience could be that:

  1. User enters URI to trust
  2. Browser fetches self-signed cert, asks user if they want to  
trust this site
  3. User confirms request
  4. Cert is added

Somewhere in there the implications of what accepting a self-signed  
cert means should be shown. Until the user performed these steps, the  
page would be rendered with some sort of warning about how the  
browser's security settings need to be configured to view the site.

This is going to, ultimately, lead to sites giving illustrated work  
around guides. Hopefully in our overall effort to rebuild the way we  
display security context, though, that sort of workaround will become  
less commonplace on the web and so users will know to not expect it.

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

This is pretty much the thought behind the proposed design, above.

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

As is this. Turning off indicators of encryption is an alternative to  
not rendering the page, but I'm not sure what advantage that really  
holds. My guess is that most people legitimately using SSL with self- 
signed certs don't care so much about indicators of security, they  
just want an encrypted connection.

>>> 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)?

Whomever said that we need to eliminate references to certificates  
for everything other than detailed dialogs gets my vote. We need to  
talk more about the current relationship to websites, the presence of  
encryption and an assessment (if possible) of safety, and keep  
techhie-talk about "certificates", "signatures" and "128-bit SLL" out  
of front-line view.

cheers,
mike

Received on Wednesday, 27 December 2006 21:19:28 UTC