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.