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