Netscape's use of SSL
Sun, 7 Nov 1999 11:12:48 -0800
At 8:58 +0000 99/11/07, Ben Laurie wrote:
>Norman Hardy 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!
>> 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.
You assume that the browser compares the "name on the cert" with the domain
name in the URL. I wish this were so. It may be so. (Tyler thinks it is.) I
have heard from someone who I think read the code that it was not so. That
theory was merely that people with certs were obviously good and the only
the rare user would actually want to see which good guy he was talking to.
I would be much comforted by a Netscape page that explained what the
browser did. A test is also feasible and useful. I hope I am wrong. I wish
I were sure one way or the other.
>> 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
I agree that it was not intended that to be used as an application session,
and I think that that is a pitty. The available schemes to maintain
application session context seem baroque and error prone to me. I think
that application session duration must usually be compatible with a human
remembering some context. Sounds like a good match to me.
>> 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
>You can find out which ciphersuites are available, and even disable them
>>(History) that defines the state of the browser's back button. If a
>>edition was published before Netscape 4 and describes a tentative fix for
>>this. (See section 20.4.) I am very suspicious.
>So don't put the number in the URL. Someone standing behind you can see
Perhaps I misunderstand: I think an URL does not appear on the screen but
is what is between the quotes following the "href=". Does "link" refer to
what the browser copies to the screen from between the html tags? What is
left of the Droplet scheme without numbers in URLs? (I had meant to include
"Droplet" in the original mail.)
>"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
Norman Hardy <http://www.mediacity.com/~norm>