Netscape's use of SSL

Norman Hardy norm@agorics.com
Sat, 6 Nov 1999 23:17:12 -0800


It has been a while since I looked at the SSL specs. The specs seemed fairly clear but they called out a few decisions that any particular implementation must make. I have never seen a document from Netscape or Mocrosoft saying which decisions their browsers made. I recall that one of the options was Diffie-Helman vs. RSA. With DH each side could identify the other securely by prior knowledge of the other's public key. I am told that Netscape uses RSA only. My bank, <https://ihbprod5.bankamerica.com/ihb-bin/ihbcgi> has a certificate issued by RSA Inc. I think that they issue only certs for RSA key pairs.  This means that the site transmits its certificate to the browser. The browser looks for a signature on the cert from one of the ungodly large number of cert issuers. The browser knows the public keys of each of these issuers (CAs). The browser user can selectively enable or disable each of these CAs. The cert carries the site's public key which can be used by the browser to send a secret session key to the site. It is awkward to query Netscape to see the "name on the cert". Netscape won't show you the finger print of the site's public key but it does show you the cert's finger print which I presume is a hash of the cert which includes the public key.

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!

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. If you could include in the URL, 64 to 80 bits of the finger print of the site's public key and if you could get your browser to compare those URL bits with bits of the hash of the delivered public key this problem would be solved.

Another weakness that I think plagues Netscape is that the duration of a session, in which a secret key is shared between the browser and site, is not available to application logic at the site. Such logic now has a difficult time associating successive https transactions from the same browser with each other.

Many of the claims above are very different from what I first imagined. They stem from random comments of others and fragmentary evidence. I have not and probably will not read the code. I have seen no documents from Netscape beyond saying that they use SSL. That leaves far too much lattitude.

Another thing is that JavaScript "code" is able to read the stack (History) that defines the state of the browser's back button. If a protected page holds an URL to a hostile page with such JavaScript, the hostile JavaScript can learn the swiss number for the protected page. The is only a pitfall but it is very serious. O'Reilly "JavaScript" second edition was published before Netscape 4 and describes a tentative fix for this. (See section 20.4.) I am very suspicious.