Netscape's use of SSL

Tyler Close tyler@waterken.com
Sun, 7 Nov 1999 12:50:28 -0500


Oops.

I was working between the two emails while replying. Sorry
for any confusion.

Tyler

> -----Original Message-----
> From: owner-e-lang@eros-os.org
> [mailto:owner-e-lang@eros-os.org]On
> Behalf Of Ben Laurie
> Sent: Sunday, November 07, 1999 12:29 PM
> To: Tyler Close
> Cc: Norman Hardy; E Language Discussions
> Subject: Re: Netscape's use of SSL
>
>
> For the record, I didn't write the stuff
> attributed to me here. Norman
> did.
>
> Cheers,
>
> Ben.
>
> Tyler Close wrote:
> >
> > Ben Laurie 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!
> >
> > Was it also Yahoo's site?
> >
> > I've spent some time reading the available docs
> at Netscape
> > and I thought that they also notify the user if the site
> > name on the cert does not match the site name in the
> > requested URL.
> >
> > > 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.
> >
> > The purpose of the PKI is to ensure that the
> bogus site does
> > not have a cert for the victim site. I think
> your argument
> > presumes failure of the PKI without stating it. I am not
> > naive enough to believe that the PKI is
> infallible, but it's
> > an important enough structure that presumption
> of failure
> > needs to be stated.
> >
> > If the site does not have a cert for the site
> requested in
> > the URL, then the site should never see the URL. SSL
> > authentication happens before the HTTP protocol
> even starts.
> >
> > > 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.
> >
> > I've found Netscape documentation to be very
> difficult to
> > get information from. The Microsoft Javascript
> documentation
> > is superb.
> >
> > The following is taken from:
> >
http://msdn.microsoft.com/workshop/Author/dhtml/reference/ob
> jects/obj_history.asp
>
> ---BEGIN EXERPT----
> For security reasons, the history object does not expose
the
> actual URLs in the browser history. It does allow
navigation
> through the browser history by exposing the back, forward,
> and go methods. A particular document in the browser
history
> can be identified as an index relative to the current
page.
> For example, specifying -1 as a parameter for the go
method
> is the equivalent of clicking the Back button.
>
> This object is available in script as of Microsoft®
Internet
> Explorer 3.0.
> ---END EXERPT----
>
> Exposing the contents of secure pages to JavaScript code
> from another site would be a gross security oversight for
> any secure web application. So far, I have found that
gross
> security oversights have either been taken care of or do
not
> exist.
>
> Tyler

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