- Published on
SSL/TLS
- Authors
- Name
- Bowen Y
How the SSL/TLS is used when users access websites via HTTPS?
SSL/TLS (Secure Sockets Layer/Transport Layer Security) is a protocol for securing internet communications. It's used extensively for securing data transfer, especially in HTTPS, which is the secure version of HTTP used for web browsing. Here's a simplified overview of how SSL/TLS works when you access a website via HTTPS:
Client-Server Handshake Initiation
- Client Hello: When you enter an HTTPS URL in your browser (the client), it initiates a connection to the server hosting the website. The client sends a "Client Hello" message, which includes the TLS version it supports, a list of supported cipher suites (algorithms for encryption, decryption, and authentication), and a randomly generated number (Client Random).
Server Response
- Server Hello: The server replies with a "Server Hello" message, selecting a TLS version and a cipher suite from the list provided by the client. It also sends a randomly generated number (Server Random).
- Certificate: The server sends its SSL/TLS certificate, which contains its public key and is digitally signed by a trusted certificate authority (CA). This ensures the authenticity of the server.
- Server Key Exchange (if needed): For some cipher suites, the server sends additional key exchange information.
Client Verification and Key Exchange
- Certificate Verification: The client verifies the server's certificate against a list of trusted CAs. If the verification fails, the connection is terminated (e.g., warning about an untrusted certificate).
- Pre-Master Secret: The client generates a "Pre-Master Secret," encrypts it with the server's public key (from the certificate), and sends it to the server.
- Key Generation: Both the client and server use the Pre-Master Secret along with the Client Random and Server Random to generate a "Master Secret." From this, they independently generate a set of symmetric keys (used for encryption and decryption of data).
Handshake Finalization
- Client Finished: The client sends a "Finished" message, encrypted with the symmetric key, indicating the end of the handshake process from its side.
- Server Finished: The server responds with its own "Finished" message, similarly encrypted.
Secure Data Transfer
- Once the handshake is complete, all data transferred between the client and server is encrypted with the symmetric keys. This includes the HTTP requests and responses.
Session Closure
- Either party can send a message to close the session securely. The symmetric keys are discarded at the end of the session.
This process ensures that the data transferred between your browser and the server is encrypted, protecting it from eavesdroppers. Additionally, the verification of the server's certificate ensures that you are communicating with the intended server, not an imposter (man-in-the-middle attack prevention).
How the SSL/TLS certificate is issued?
The process of verifying the server's SSL/TLS certificate against a list of trusted Certificate Authorities (CAs) is a crucial aspect of the SSL/TLS protocol, ensuring the authenticity and integrity of the certificate. Here's how this process works:
Certificate Issuance: When a server obtains an SSL/TLS certificate from a CA, it first generates a key pair consisting of a public key and a private key. The server keeps the private key secret and sends a Certificate Signing Request (CSR) to the CA, which includes the public key and the server's identifying information.
Certificate Signing: The CA verifies the identity and legitimacy of the server. Upon successful verification, the CA signs the server's certificate using the CA's own private key. This signature is an essential component of the SSL/TLS certificate, as it links the server's public key to its identity and to the CA's trustworthiness.
Certificate Distribution: The signed certificate is returned to the server. This certificate includes the server's public key, identifying information, and the CA's signature.
Client Verification Process:
- When a client (like a web browser) connects to the server via HTTPS, the server presents its SSL/TLS certificate.
- The client checks whether the certificate is signed by a trusted CA. Operating systems and browsers come with a pre-installed list of trusted CAs and their public keys.
- The client uses the CA's public key (from its own trust store) to verify the CA's signature on the server's certificate. If the signature is valid, it means the certificate is authentic and the server is who it claims to be.
- The client also checks other certificate attributes like the validity period, domain name, and whether the certificate has been revoked.
Role of the CA's Private Key: The CA's private key is used only for signing certificates and is securely stored by the CA.