Netscape's use of SSL

Norman Hardy norm@netcom.com
Sun, 7 Nov 1999 11:11:29 -0800


At 11:54 -0500 99/11/07, Tyler Close wrote:
>Ben Laurie wrote:
>> Out of shear preversity I often check the name on
>> the cert. Once I discovered that way that the
>> vendor had hired Yahoo to do their online web
>> retailing. It was Yahoo's cert!
>
>Was it also Yahoo's site?

Yes, I just now rechecked. Thanks.

>I've spent some time reading the available docs at Netscape
>and I thought that they also notify the user if the site
>name on the cert does not match the site name in the
>requested URL.

If you come across that info again I would sure like a
pointer to it. That would be as it should be.

>> It is tedious to check the cert on each URL
>> reference (about 10 sec when you rember exactly
>> how). Commonly the "name on the cert" is the
>> domain name from the URL. I have seen exceptions.
>> The danger for not checking is DNS spoofing that
>> directs  the URL reference to a site with a cert,
>> but not the one you planned to visit. The bogus
>> site learms the swiss nmber and the jig is up.

Given your assumption about browser behavior, I agree.
Including an 80 bit public key fingerprint in the URL
takes the CAs and the DNS out of the TCB,
but only if you can get the browser to do the comparison.
The browser would then not need to do the domain
name comparison. The URL with PK fingerprint
would be strongly bound to the private key held
at the site. No other institutions would be involved.
The SPKI people have said this more clearly.

>The purpose of the PKI is to ensure that the bogus site does
>not have a cert for the victim site. I think your argument
>presumes failure of the PKI without stating it. I am not
>naive enough to believe that the PKI is infallible, but it's
>an important enough structure that presumption of failure
>needs to be stated.

I didn't think that I was blaming the problem on on the
PKI but I will think about that.
...

>The following is taken from:
>http://msdn.microsoft.com/workshop/Author/dhtml/reference/ob
>jects/obj_history.asp

Thanks for the pointer. I shall look.

>---BEGIN EXERPT----
>For security reasons, the history object does not expose the
>actual URLs in the browser history. It does allow navigation
>through the browser history by exposing the back, forward,
>and go methods. A particular document in the browser history
>can be identified as an index relative to the current page.
>For example, specifying -1 as a parameter for the go method
>is the equivalent of clicking the Back button.
>

Sounds like a capability, but you can't pass it.
Norman Hardy  <http://www.mediacity.com/~norm>