HTTPS authentication and session hijack

Question

When I type a URL for example, www.google.com for the first time in my browser. I am sure that something is sent out containing the URL. Then the returned HTML page is displayed on the screen.

How does my browser make sure that the server who responds to my request is the real Google's Server not someone else's server (Man-in-the-middle)?

I can see that an HTTPS connection is also established. I believe that this has something to do with the above question.

Can anyone anwser this question in detail with my www.google.com example?

I know what is public key and private key. I know that public key can be used to encrypt a message then its private key is used to decrypt. Private key can be used do digital signature and public key can be used to verify this signature. But I don't know how they are applied in the www.google.com case.

As for using the public key to verify the signature, how do we do it? We use the public key to decrypt the message to see if we can get something that is previously defined?

Edited

1. Once the browser knows that it is a real google server that sends back the page, how can browser make sure that the page content itself is not modified by someone else? Is the first page sent back already encrypted?
2. Is symmetric encryption used for the following requests and responses?
3. Is the URL itself is encrypted?

Answer 1

Once the browser knows that it is a real google server that sends back the page, how can browser make sure that the page content itself is not modified by someone else?

The browser verifies that the certificate sent back in the SSL handshake is signed by a Certificate Authority (CA) that the browser trusts, and checks that certain fields are set to the correct value (e.g. Subject or Alternative Name is set to the displayed domain name and the valid from and to dates are current).

There can be multiple certificates in the chain if intermediary certificates are used, which is likely. As long as the second to last certificate in the chain is signed by a trusted root then everything is good.

Is the first page sent back already encrypted?

Yes, as soon as the SSL handshake is made, everything is encrypted. This includes any data in the initial request sent from the browser (e.g. cookies or query string).

Is symmetric encryption used for the following requests and responses?

Yes, although the keys are a function of random numbers generated by both client and server and a "pre master secret" which is sent from client to server encrypted by the certificate public key (or encrypted by one time generated keys in the case of Diffie-Hellman).

Is the URL itself is encrypted?

The domain name is sent in cleartext for the Server Name Indication extension, and also the DNS lookup and destination IP can also be known by an evesdropper on the connection.

The URL path and query string are encrypted though.

Answer 2

They use certificates to verify identities and signatures. When the server responds to you, this contains a certificated that is being issued for that specific host. In your example this would be www.google.com This provides some sort of trust because the root certificate is contained within your browser installment. Speaking of a root certificate you start to build a chain of trust and one certificate is signed by another certificate until it reaches the root of this trusttree. These are installed locally on your browser and are therefore very hard to spoof for an attacker.

Answer 3

https uses signed certificates to ensure the identity of the responding server.

The request is sent to the IP address your name resolution claims the name resolves to. That is not really reliable, since you yourself can easily alter that resolution.

The response from the server however contains a certificate that has been issued for the hostname (www.google.com here). This also does not yet provide the security you are looking for, but it brings us closer.

To verify if the certificate tells the truth your local browser tries to verify the certificate (its content). That is done by using a "certificate chain". A certificate can be signed with another certificate. If you trust that other certificate, then you can also trust those certificates that have been signed with the one you trust. That way a chain is created that reaches up to so called "root certificates". Such are certificates that are locally installed inside your system, so known and available to your browser, so they cannot be spoofed by an attacker.

---

Reality is a bit more complex, as always, but the above should give you an idea of how things work.

Note: you can also create a certificate yourself, you can even sign it yourself. This actually is helpful if you are just interested to establish an encrypted connection to your own https server, for example. But such self signed certificate does not prove the servers identity. That can only be done by using a certificate that has been signed the way described above.