Browsers and SSL

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 Microsoft 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 DH public key, g^x. I am told that Netscape uses RSA only. My bank, has a certificate issued by RSA Inc. I think that current CAs (Certificate Authorities) issue only certs for RSA key pairs. 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 CAs that it knows and that the Browser user has not disabled. 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 perversity 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 also was Yahoo’s site.) I wish I knew whether the browser compared the domain name in the URL with the name on the cert, and warned on mismatch. I now have anecdotal evidence that it does. This evidence impacts some arguments below.

It is tedious to check the cert on each URL reference (about 10 sec when you remember exactly how). Commonly the “name on the cert” is the domain name from the URL. The danger for not checking is DNS corruption that directs the URL reference to a site with a cert, but not the one you planned to visit. The bogus site learns the swiss number 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. See this for ruminations and rhetoric on this subject.

Another weakness that I think plagues Netscape is that the duration of a session, during 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. If a site application could attach context to a secret key then several confusion attacks would be naturally avoided.

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

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 browser follows an URL from a protected page to a hostile page with such JavaScript, the hostile JavaScript can learn the swiss number for the protected page. This is only a pitfall but it is very serious. O’Reilly’s “JavaScript” second edition was published before Netscape 4 and describes a tentative fix for this. (See section 20.4.) I think that it won’t work.

SSL Nexus