From: Eric Murray <ericm@lne.com>
Date: Mon, 20 Jan 1997 10:25:49 -0800 (PST)
To: Bill Frantz <frantz@netcom.com>
Subject: Re: Server Authentication
Message-ID: <199701201825.KAA15083@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


Bill Frantz writes:
> 
> I recently came aware of an interesting problem in server authentication.
> I.e. How does a browser plugin validate the server it is working for.
> There are many reasons for a plugin to want to validate its web server
> including contractual relations, but the one that most appeals to me is
> that the plugin provides access to confidential data which is used in an
> application distributed between the client machine and the server.  Since
> the data is confidential, the plugin doesn't want to send it to just any
> server who can serve up a web page in the correct format, so it needs to
> authenticate the server.
> 
> Now the obvious way to validate the server would be through the
> certificates exchanged when the SSL session was set up.  (I am assuming a
> SSL session here because you shouldn't send confidential data over a
> non-encrypted link.)  However, I haven't found an API where the plugin can
> discover the certificate used by the server, so it appears you have to roll
> your own.

I think that you can get access to the server's certificate.
I know you can from the CGI interface.  Unfortunately it's the
raw ASN.1 encoded certificate, so you would have to ASN.1 decode it.
Bleah.

If the SSL handshake completes, then you can assume that the client
has verified and authenticated the server certificate.   The only problem
would be that the authentication might not be up to the plugin's standards-
i.e.  a connection to www.foo.com is somehow intercepted by
www.ripoff-plugins.com.  The server www.ripoff-plugins.com presents a cert
who's name is www.foo.com.  The browser correctly presents a pop-up dialog
noting the discrepancy, and the luser operating the client clicks
on the 'OK' button, allowing the SSL handshake to finish.  Oops.