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.