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