Norman Hardy wrote:
> 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 t!
> 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.
No, it wouldn't - the spoofer would obviously also spoof the (source of the) original URL and hence the fingerprint included in it. Also, Netscape warns you if the cert doesn't match, so I don't see why you should have to check manually. What you do have to check is that you are at the URL you thought you were at.
> 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.
This is silly: the SSL session is not intended as an application session - there's no requirement for the browser to use a single SSL session, for example, nor for the server to reuse it if asked, and the timeout may, for security reasons, be wildly different from the timeout on an application session. If you want an application session, you should create one in the usual way, not attempt to abuse the SSL session as one.
> 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.
You can find out which ciphersuites are available, and even disable them selectively.
So don't put the number in the URL. Someone standing behind you can see that, too.
-- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi