Thanks Tom.. Ahh.. that makes it even more efficient; since the symmetric key is the only one required for encryption/decryption. Moreover, this symmetric key is only known to the client and the server.
Thanks !!!! Thanks and Regards, Ajay On Mon, Mar 26, 2012 at 2:52 PM, Tom Evans <tevans...@googlemail.com> wrote: > On Mon, Mar 26, 2012 at 10:12 AM, Ajay Garg <ajaygargn...@gmail.com> > wrote: > > Thanks a ton Sander. > > > > So on session setup-phase, the server sends the public-key to the client > > (which would hardly be a bother, even if it is intercepted by a > > eavesdropper). This public key is then used to encrypt the data on the > > client, send over the wire, and decrypted by the server's private key. > > > > That explains the client-to-server-transfer. > > > > However, just one last confirmation regarding the > server-to-client-transfer. > > Is another set of public-private (session) keys pair created? (This would > > then explain the server-to-client transfer seamlessly, wherein the client > > would send the (session) public key to the server; server would encrypt > data > > using this (session) public key; send the data over the wire; and the > client > > would then decrypt data using the (session) private key). > > > > Thanks Sander. You have really been a darling in all the help ;-) > > > > Thanks and Regards, > > Ajay > > > > > > No, that is not how SSL works. A brief synopsis: > > http://stackoverflow.com/questions/188266/how-are-ssl-certificates-verified > > More information can be found by searching the internet for "how does SSL > work". > > Cheers > > Tom > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > >
