On Mon, 2005-06-06 at 06:05 -0700, bruce wrote:
> but you still haven't addressed my problem/issue/question...
How come?
> and that's how do i as a user (not an app) know that this is the right site
> for the url i entered... my fear is that a malicious site, could simply fake
> the information he's providing, to 'look' like the actual/real site...
Let me paint the scenario in very simple terms, omitting details and
variations of key negotiation, etc, because there is a thicket of
options there...
The client connects to an SSL site (https://...). The server presents
its certificate, containing its public key and bearing a signature by a
CA your browser software has got the public key of.
The client looks at the certificate and finds it acceptable, because the
signature verifies ok and it trusts the CA. So far, nothing has been
established in terms of authenticity, because anyone could have fished
that certificate out of the air.
Next, the client fetches the server's public key from the certificate
and uses it to encrypt its part of the session key. The session key is a
key used with a symmetric cipher (such as 3DES, AES, ...) to encrypt all
traffic of the upcoming conversation.
The server can only use the session key if it can decrypt the client
supplied part, and it can only do this if it possesses the private key
that matches the public key contained in the certificate it presented.
Hence, if the server presented a certificate harvested from somewhere it
won't be able to communicate with the client, and the SSL session setup
will fail.
The possible scenarios for breaking this mechanism (apart from
weaknesses in algorithms or implementations) are:
* a legitimate server's private key was disclosed and is used by
an imposter;
* the CA's private key was disclosed (OMG!) and used by an
imposter to sign a certificate containing a false CN;
* the CA didn't use proper care and issued a valid cert to an
imposter;
Hope this makes it a bit clearer. If your able to setup an SSL session
with a web server, it's extremely likely that it is either legitimate or
one of the above has happened.
Cheers
Steffen.
Attachment:
signature.asc
Description: This is a digitally signed message part
