The overview is a rough one. It does not take into account the TLS version, nor it goes into technical details. For those please do refer to the corresponding RFCs.
When a Client (browser) connects to а TSL Server (website) what happens is:
- TCP handshake. The Client probes the Server if the latter is available.
- TLS handshake
2.1 Hello phase
The Client sents:
- What TLS version it supports
- Session ID
- The Cipher Suit it supports
- Compression – if it is to be used
- Random number
The Server responds with:
- TLS version that must be used
- Session ID
- The Cipher Suit it supports
- Compression
- The servers (digital) certificate along with Public Key
How the cipher is chosen is another matter but in the general case it is the Server that sets the cipher, not the Client. If any step fails – the whole process fails.
The Client verifies the Server’s certificate. The verification consists of:
- checking the Server’s certificate expiration date, the certificate must not have expired
- the root (CA) and/or intermediate certificate that has signed the Server one; this is done through explicit trust, i.e. the Client must explicitly trust the signing certificate (and yes, they must not have expired and must not be revoked)
- additionally the Client may use CRL and/or OCSP to verify the Server’s certificate has not been revoked
- the Client may choose to trust the Server’s certificate even if it is not signed by a CA but rather a self-signed one (when the Server vouches for its own authenticity)
Only after the Client successfully verifies the Server’s certificate the TLS handshake continues with the KEX – KeyEXchange.
2.2. Key Exchange
The Client computes a pre master key and uses the Server’s Public Key to encrypt and send it. The Server uses its Private Key to decrypt the pre master key. Afterwards both Client and Server must agree on a session key that will be used to encrypt and decrypt the data / payload. If all goes well – yei – encrypted data flows, if not – the connection is broken.
The image does not cover the case where the Client needs to authenticate to the Server using its own certificate. It does not cover how the Client and Server decide which cipher to use nor it displays anything about the cryptographic parameters shared between both parties. It displays a generalized and (sort of) simplified TLS session that is the most widely used one – when one opens an HTTPS enabled website. It’s worth nothing that in this case the Client does not ever has to generate its own Private Key nor Public one. On the contrary all the Client is doing is verifying the Server’s certificate and then using the Server’s Public Key to encrypt and send the pre master (session) key that both will be using once the handshake completes successfully.
I’ve intentionally did not mentioned what is the process behind the scenes, if RSA is used or Diffie-Hallman (DH) or ECDH / ECDHE, what all that means & etc. The information is really too much to get into it, but we gonna. Stay tuned.