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

[William.Soley@Eng.Sun.COM (William Soley)]

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