Netscape's use of SSL

Ben Laurie ben@algroup.co.uk
Sun, 07 Nov 1999 21:33:24 +0000



Norman Hardy wrote:
> 
> 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.

Well, I am. The browser does compare the cert. This actually causes a
FAQ for Apache-SSL, which is "why can't I use name-based virtual hosts
with SSL?" - the problem being that the cert doesn't match the URL, and
the browser bleats loudly about bad guys and men-in-the-middle and
stuff.

> >> 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.
> 
> 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.

Sure. A good match between an application session and a user. But a very
poor match between the appropriate lifetime of a cryptographic object
and any other consideration. Cookies are the appropriate mechanism.

> >> 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.
> >
> >> 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.
> >
> >So don't put the number in the URL. Someone standing behind you can see
> >that, too.
> ...
> Perhaps I misunderstand: I think an URL does not appear on the screen but
> is what is between the quotes following the "href=".

Typically what you click on goes on the screen (or in the history). So a
URL appears in both places.

> 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.)

The secret bits should be conveyed by something other than the URL. For
example, POST data in a form, or output from a client-side Java app
(also posted).

Cheers,

Ben.

--
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