Browser and Server SSL communication

[Rajan Chinna]

I was trying to understand SSL communication between browser and webserver. After reading from web its bit confusing to understand. Can somebody please correct me if I understand incorrectly.

Assuming the site is a bank application, First the webserver should sign and get private & public key from CA. When a user try to connect the site https:\\mybank.com, the public key is transfered to the browser thru which it knows that its a trusted site. Once the initial handshake is established the client encrypts the data with server public key and the server will decrypt the data with its private key. Any data sent from server is encrypted by its private key and the same is decrypted by client using server public key.

Is the above scenario correct OR the browser too have its own private & public keys stored locally?

[suekar meredilko]

Originally posted by Rajan Chinna:
I was trying to understand SSL communication between browser and webserver. After reading from web its bit confusing to understand. Can somebody please correct me if I understand incorrectly.

Assuming the site is a bank application, First the webserver should sign and get private & public key from CA. When a user try to connect the site https:\\mybank.com, the public key is transfered to the browser thru which it knows that its a trusted site. Once the initial handshake is established the client encrypts the data with server public key and the server will decrypt the data with its private key. Any data sent from server is encrypted by its private key and the same is decrypted by client using server public key.

Is the above scenario correct OR the browser too have its own private & public keys stored locally?

You are right. One thing more to add is for SSL or any technology which uses PKI , the crux is how to believe on the public key that is provided by the webserver (basically the server party). for this a Certification Authority such as Verisign provides a certificate, certifiying that the webserver Pub key has been verified and can be trusted.

how this is done is that your browser contains the root certificates from the CA. Certificate chaining technology is used in this case. These certificates are pre-installed. You can see them in IE6.0 at internet options-->content-->certificates-->trusted root certification authorities.

Now if your application is using client authentication as well, then you will have to install a certificate in your browser or if you are using client authentication for email, your email client would require you to install the client certificate.

Another thing to note is you mentioned the webserver need to get the Pub and priv keys from the CA. Well that is right, but you can also generate self-signed CA key pairs using Keytool or some other alternatives. In which case you are yourself your CA. But this wont be used in an internet scenario and more applicable for an intranet scenario for trusted communication. Because you are basically saying that hey, here is my trusted key within my domain, since you are in my domain you can trust me.

hope that clarifies

[Rajan Chinna]

Lets consider this 2 scenarios....
1.Browser and secured server communication.
2.B2B client application and secured server communication.

1.
In this scenario it seems the eavesdroper can hack if he knows the server public key rite? I guess here the browser don't have its own private/public key however it make use of server's public and validate against truststore. Is that how it works? Can we say this is Symmetric cryptography?

2.
In this scenario the client & server might have its own private/public keysets. This seems to be more secured. I guess this scenario is used in B2B where client is not a browser rather its an application. Is this a valid scenario? Can we say this is Asymmetric cryptography?

[Rajan Chinna]

Please take a look at this url
How SSL works
It says the browser will have its own private & public keys....

1.Does the browser comes with default private & public keys?
2.Is the same key used across all secured sites communications?
3.Where should we mention to use symmetric or asymmetric cryptography?

[ May 17, 2006: Message edited by: Rajan Chinna ]

[suekar meredilko]

Originally posted by Rajan Chinna:
Please take a look at this url
How SSL works
It says the browser will have its own private & public keys....

1.Does the browser comes with default private & public keys?
2.Is the same key used across all secured sites communications?
3.Where should we mention to use symmetric or asymmetric cryptography?


[ May 17, 2006: Message edited by: Rajan Chinna ]

SSL solves the problem of exchanging keys (secret/symetric)by using asymmetric keys. These keys are defined in pairs of public and private keys.

public key is freely available to anybody. The private key is known only to the server(webserver). The keys have two important properties:

(1) Data encrypted by the client using the pubic key can be decrypted only by the server's private key. Due to this property of the keys, the
client is able to send secure data that can be understood only by the server.
(2) Data encrypted to by the server's private key can only be decrypted using the public key. This property is useful in a client level
authentication of the server. If the server sends a known message (say the name of the server), the client can be sure that it is talking to the
authentic server and not an imposter if it is successfully able to decrypt the message using the public key.

Note that property (1) allows us to use conventional secret keys. A secret key can be sent by the client as data that has been encrypted using
the public key. This secret key can be decrypted only by the server. Once the server gets the key, the client and the server are able to
communicate using this secret key.

The public/private key based encryption is used only for handshaking and secret key exchange. Once the keys have been exchanged the
symmetric secret keys are used. This is done for two reasons:

(1) Public/private key based encryption techniques are computationally very expensive thus their use should be minimized.
(2) The secret key mechanism is needed for server to client communication.

[suekar meredilko]

When a web browser connects to a site via SSL (which is caused by the use of the 'https:' at the beginning of the url), it checks three things about the certificate:

1)Does it know the Issuer and did the Issuer sign the certificate? A web browser knows about a set of Issuers (called Certificate Authorities) when it's installed on the machine (the Issuer certificates are part of the files that make up the web browser).
2)Is the certificate valid right now or has it expired?
3)Is the certificate for the machine we've contacted? If the url was https://www.xyz.com/whatever then the certificate must be for www.xyz.com. The convention used is to store the name of the server machine in the CommonName slot of the Subject Identifier field of the certificate.
If all three tests pass then the web browser silently accepts the certificate and does a secure web page access. If any of the tests fail then the web browser notifies the user and waits for a response. Each browser displays the failure differently.

For example, IE shows which of the three tests passed and which failed while the Netscape just says that it received an invalid certificate. In both cases the person using the web browser is given the option of continuing with the web access.


Transmission will still be secure if it is elected to continue. The only issue in doubt is the authenticity of the web server.