On 6/6/05, Steffen Kluge <kluge@xxxxxxxxxxxxxx> wrote: > On Sun, 2005-06-05 at 21:42 -0700, bruce wrote: > > as i understand the ssl process... the browser hits the ssl site.. the site > > returns some information to me, the browser. my question/statement, if i > > know what the information shoudl be from the server with the ssl cert, then > > why couldn't i somply craft a response on my server, and send the > > information back to the browser... > > The information sent to the client is the server's public key bearing > some CA's signature (a.k.a. a certificate). The CA's signature vouches > for the fact that the key pair to be used really belongs to you (the > server). In order to play ball you don't just need the certificate (or > public key - that's, err, public), you also have to have the matching > private key. Assuming paypal keep their private keys secure, you can > trust their SSL site, if you trust their CA. The X.509 certificate is a document signed by a trusted third-party (in fact, not directly trusted by you, but by your browser or any other SSL-enabled software), which asses the public key carried in that certificate belongs to the subject to which the certificate is expedited. The trusted third-party, called CA (Certificate Authority) has to check that the subject (user for e-mail only certs, machine for Web certs and so on) identity is valid and passes some validity checks. When connecting via HTTP/S, the remote Web server must prove that it also has/knows the private key associated with the certificate's public key. Else, anyone could stole the certificate and present it to remote clients without proving he/it is the only one authorized owner. SSL is far from perfect, as there are weak mechanisms on which it, directly or indirectly, depends, like trust chains, name resolution, hash and crypto algorithms and human intervention.
