I think the short answer is that the user won't know - this is the practical answer.
The technical answer is the the user must be
able to run an app such at MD5 against the browser code that will confirm that the
browser is legit. But of course the md5 app
might have been compromised and paranoia reigns supreme. It can be done - a secure
site can rifle thru the apps in a client's
machine and authenticate them. This technology could also be used to repair broken
sites. I suggested same to IBM 5 years
ago and it fell on deaf ears (rather - mgnt's ears). Right?
On Mon, 15 Nov 1999 16:53:42 -0800, Harry Whitehouse wrote:
>This may be slightly off-topic, so let me apologize in advance.
>
>The SSL protocol requires that the client side (say a browser) use
>appropriate crypto to read the server's certificate and verify the signature
>on the transmitted public key (using the public key of a trusted 3rd party
>such as Verisign).
>
>How can the user be certain that their browser (or other SSL3 client) hasn't
>been compromised -- or that they have a roque version of the client -- which
>will go through the motions of authenticating the server but really not do a
>proper job. The result being that the user *thinks* he/she has established
>a secure connection to the desired party, but in fact are connected to
>another site.
>
>Basically, the issue is how does one ensure (if possible!) that an internet
>client is using valid methods to verify server certificates?
>
>TIA
>
>Harry
>
>______________________________________________________________________
>OpenSSL Project http://www.openssl.org
>User Support Mailing List [EMAIL PROTECTED]
>Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
