Re: NetScape's dependence upon RSA down for the count!

On Sun, Oct 1 1995, Simon Spero wrote:

> On Sat, 30 Sep 1995, Don Stephenson wrote:
>
> > I don't think binding hostnames to certificates helps much because 
> > both hostnames and IP addresses can be spoofed and DNS servers can be 
> > subverted.  The important thing is the binding to the "service" name or 
> 
> In this particular case, hostnames do help, because they are information 
> imbedded in the url used to access the server. By verifying the hostname 
> in the certificate with the hostname in the url, you can state with a 
> high degree of confidence that the object retrieved is precisely the 
> desired object covered by this url. 
> 
Hostnames help only a little.  Often the host name belongs to the ISP that
is providing the server resources.  For example when I ordered sushi last
night from WOW, the URL was "https://www.ird.net/[...]wow[...]", but the
certificate was issued to "www.sunnyside.com" (as displayed by the
File->DocumentInformation menu item in Netscape):

Version: 00
Serial Number: 02:72:00:00:3C
Issuer:  C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
Subject: C=US, ST=California, L=Palo Alto, O=Sunnyside Computing, Inc., OU=Internet Services, CN=www.sunnyside.com


PROBLEMS:

(1) The certificate *was* issued with a host name in the CN field, but it
did not match the host name in the URL and my browser did not care to warn
me of this discrepency (I had to manually request to see the certificate
and check it myself -- not a likely precaution for Joe Sixpack).

(2) Even if the certificate did match the URL (and my browser did check it)
I still have no way to know that "Sunnyside Computing" or "sunnyside.com" or
"ird.net" is actually the authentic/official ISP for WOW and not an imposter
or MITM.

(3) Netscape is making the problem worse (yes, worse) in the next release
by allowing the user to specify their own list of trusted CAs.  (I will
elaborate on this unpopular view below.)


NON-PROBLEMS:

(1) SSL did its job.  It is only a session layer.  It assured the application
that a secure session was established with the entity named in the certificate.

(2) The sushi was very good.  :-)


DISCUSSION:

Re: problem 2, it would be better to have the certificate issued with
the subject ... O=Waiters on Wheels ... CN=www.ird.net ... so that the
browser can automatically check it against the URL and the user can be
assured that (assuming suitable CA policy) ird.net is an
authentic/official ISP for WOW.  I think the browser should check the
CN and hostname in the URL and display a popup warning if they do not
match, and (optionally but by default) display a popup whenever a new
session is started with a different certificate -- and of course show
the certificate.  This is not perfect, of course, its just better.

Re: problem 3, about how allowing the user to specify their own list of
trusted CAs is bad.  All it takes is for any web page to put up text
like ...  "Dear Joe Sixpack, in order to assure your privacy while
viewing these naughty pictures you must add the following certificate
to your such-and-such file ..." and Joe Sixpack will be happy to do
it.  Even Mary Moderately-Savy might be tricked in to doing it on the
false assumption that it would only affect security for the naughty
pictures site (that she may not care about), and not affect security for
her stock-broker.  This false assumption might be based on the fact
that the (legitimate) stock-broker uses a different CA.

-Bill

In article <199510020516.BAA21934@giane.cs.umass.edu>, futplex@pseudonym.com (Futplex) writes:
> Bill Soley writes:
> > (3) Netscape is making the problem worse (yes, worse) in the next release
> > by allowing the user to specify their own list of trusted CAs.  (I will
> > elaborate on this unpopular view below.)
> [...]
> > Re: problem 3, about how allowing the user to specify their own list of
> > trusted CAs is bad.  
> [...]
> > it.  Even Mary Moderately-Savy might be tricked in to doing it on the
> > false assumption that it would only affect security for the naughty
> > pictures site (that she may not care about), and not affect security for
> > her stock-broker.  This false assumption might be based on the fact
> > that the (legitimate) stock-broker uses a different CA.
> 
> You seem to be overstating your point a bit. The real problem here, AFAICS,
> is that the proposed protocol in the software wouldn't allow sufficiently 
> fine-grained control over the certification authority approval. The user
> should be able to specify the conditions under which a CA is to be trusted,
> not simply give a blanket approval or rejection. 
> 
> It looks as though a set of trusted (CA, site) pairs would suffice. 
> How about it, Netscape ?  Give the user the opportunity to say "I trust 
> certificates from Alfie's World of Key Certification regarding keys for
> interactions with Elvira's Copier Shack."

  We've already thought of a lot of the stuff you guys have brought up,
and tried to address them in our design.  I'm also taking note on things
we didn't think of.

  There will be various "domains" that you can trust a CA for, including
SSL, e-mail, and payment.  You will be able to enable and disable trust
for specific server certs as well.  You could say, "I don't trust
verisign, but I will trust Joe's Internet Coffee Shop(which happens
to be signed by verisign)".

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw@netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

Bill Soley writes:
> (3) Netscape is making the problem worse (yes, worse) in the next release
> by allowing the user to specify their own list of trusted CAs.  (I will
> elaborate on this unpopular view below.)
[...]
> Re: problem 3, about how allowing the user to specify their own list of
> trusted CAs is bad.  
[...]
> it.  Even Mary Moderately-Savy might be tricked in to doing it on the
> false assumption that it would only affect security for the naughty
> pictures site (that she may not care about), and not affect security for
> her stock-broker.  This false assumption might be based on the fact
> that the (legitimate) stock-broker uses a different CA.

You seem to be overstating your point a bit. The real problem here, AFAICS,
is that the proposed protocol in the software wouldn't allow sufficiently 
fine-grained control over the certification authority approval. The user
should be able to specify the conditions under which a CA is to be trusted,
not simply give a blanket approval or rejection. 

It looks as though a set of trusted (CA, site) pairs would suffice. 
How about it, Netscape ?  Give the user the opportunity to say "I trust 
certificates from Alfie's World of Key Certification regarding keys for
interactions with Elvira's Copier Shack."

-Futplex <futplex@pseudonym.com>