What is the workflow from client to server for SSL enabled sites?

Question

I have a basic question on workflow of SSL enabled sites from client browser to server. My understanding is when the browser has to access some https enabled site, the browser contacts some CAs. I am assuming that the browser will know (through hardcoded information in browser code) IP addresses of some certificate authorities(CA) and also public key of those CAs so that communication to and from CAs are secured. Then, the CAs would return the public key of the site over secured channel (via CAs keys). Then the browser sends the requests to server encrypted by this public key of server.

Is this understanding correct?. Though this raises another question that what if someone intercepts the encrypted requests and encrypted responses(between client and server), because in the picture no where client's key is coming in picture.

Edit: I think, I was missing the role of session key in data exchange and how this session key is established.

Answer 1

No, it is incorrect.

Here is a quick breakdown of how it works: First, the client contacts the server and sends a "Client Hello", to which the server replies with a "Server Hello". These messages include version numbers, supported cipher suites and more. Among others, they also include the leaf certificate, as well as all intermediate certificates. The certificate authority, also called the "root certificate", is usually not sent.

The client verifies whether or not the leaf certificate is valid, as well as the signature of this certificate, together with the intermediate certificate. The client then checks whether or not the certificate, which signed the top-most intermediate certificate, is in the trust store of the client. If so, the chain of trust is established - if not, the certificate is considered untrusted.

Next, it is verified whether or not the certificate is revoked. For this, two mechanisms are used: CRL (Certificate Revocation Lists) and OCSP (Online Certificate Status Protocol)

If CRL is used, the certificate includes a link to where the revocation list is published. This list must also be signed by a CA, but I don't know if it must be the same CA as the one who signed the certificate - in practice, it will be the same. A certificate revocation list is exactly what it says on the tin: A list of certificates which have been revoked. The client checks whether the certificate in question is on that list, and if so, it does not trust the connection.

If OCSP is used, the certificate needs to point to and endpoint by the certificate authority. The client then sends an OCSP request to the endpoint, asking if this certificate is valid, and the endpoint responds with "Yes", "No" or some other stuff (Certificate unknown, etc..)

OCSP Stapling can also be used, in which the server periodically queries the OCSP endpoint about its own status, then returns a signed response together with the Server Hello. In essence, it says "Hi, I'm and said 2 minutes ago I am valid". The advantage is that it saves the client from asking the endpoint, but the downside is many servers don't support it.

---

What about Man-in-the-Middle attacks?

Since the Certificate Authority's keys are already on my machine, the attacker can't really "forge" them. They would need administrative access on my machine to add a new CA or modify an existing one - but in that case, I have already lost.

Any other changes in any of the parameters, such as the address of the CRL or OCSP endpoint, or the data in those responses, would lead to an invalid verification.