use case: "recognizing site, not identity"? (Re: Browser security warning)

Mike, Stephen,

between (mostly) the two of you, I think there's another use case
seed floating around in this thread that could be roughly described
as being about some party accessing a site, and essentially only
being interested in talking to the same site (as opposed to being
interested in some more general notion of identity of that site).
That use case could lead to self-signed certificates and to deriving
trust in such certificates by them being the same.

I wonder if one of you would mind writing up a little story
involving self-signed certificates for tomorrow.

(I see this as different from the "add a new certificate to the
trust root" case.)

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>







On 2006-12-27 16:18:52 -0500, Mike Beltzner wrote:
> From: Mike Beltzner <beltzner@mozilla.com>
> To: "Stuart E.Schechter" <ses@ll.mit.edu>
> Cc: public-wsc-wg@w3.org
> Date: Wed, 27 Dec 2006 16:18:52 -0500
> Subject: Re: Browser security warning
> List-Id: <public-wsc-wg.w3.org>
> X-Spam-Level: 
> X-Archived-At:
> 	http://www.w3.org/mid/A7EA42BC-B5EF-46D0-AE07-69AF9823CEC3@mozilla.com
> 
> 
> 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 Monday, 8 January 2007 14:08:23 UTC