Transport Layer Security (TLS) is a protocol designed to provide secure communications over a computer network. Below is a simplified step-by-step flow of how TLS handshake works when a user accesses a website using HTTPS:
1. DNS Resolution:
The user enters the URL `https://cordero.me` into the browser.
The browser contacts a DNS server to resolve the domain name (`cordero.me`) to an IP address.
2. TCP Handshake:
Before TLS can even start, there needs to be a reliable connection in place. So, the browser initiates a TCP handshake with the server at the IP address provided by DNS.
The browser (client) sends a “ClientHello” message to the server. This message includes:
The highest TLS version the client supports.
A list of supported cipher suites.
A randomly generated value called a “client random.”
Other extensions (e.g., Server Name Indication to specify which domain’s certificate it wishes to check).
The server replies with a “ServerHello” message, which contains:
The TLS version they will use (usually the highest version they both support).
The cipher suite they will use from the client’s list.
A “server random” is another randomly generated value.
The server’s digital certificate (typically an X.509 certificate). This certificate contains the server’s public key and is signed by a trusted Certificate Authority (CA). The client will verify this certificate against its list of trusted CAs.
5. Certificate Verification:
The client verifies the server’s certificate:
It checks if it’s signed by a trusted CA.
It verifies it hasn’t expired.
Ensures it hasn’t been revoked.
Makes sure it matches the server’s address (domain).
6. Key Exchange:
To securely exchange data, the client and server need to compute a shared secret without transmitting that secret. This is accomplished using asymmetric encryption during this phase:
The client generates a “premaster secret” and encrypts it with the server’s public key (from the server’s certificate), then sends it to the server.
The server decrypts the premaster secret using its private key.
7. Session Key Generation:
The client and the server use the premaster secret and the random values exchanged earlier to compute the same session keys. These keys will be used for symmetric encryption and integrity checks.
Both the client and server exchange “Finished” messages, which are encrypted with the session key. This is the first actual encrypted data of the TLS session, proving that both parties have the same keys and encryption is working.
9. Data Transfer:
Now, the TLS handshake is complete, and both sides can securely exchange data. All data (e.g., HTTP requests and responses) are encrypted using the established session keys.
10. Session Termination:
When the session ends (e.g., the user closes the browser or after a set period), the client and server will exchange encrypted “close_notify” alerts to securely close the session.
In summary, TLS provides both authentication (through certificates) and encryption (through a series of key exchanges and cryptographic operations). When you see “https://” in your browser’s address bar, it means that your connection to the server is secured using TLS.