Two Types of Cryptography Working Together
TLS (Transport Layer Security) relies on two fundamentally different types of cryptography, each used for a different part of the job. Asymmetric cryptography — where a public key encrypts and only the matching private key decrypts — is used during the handshake to authenticate the server and safely establish a shared secret. Symmetric cryptography — where the same key both encrypts and decrypts — is used for all the actual data transfer, because it is orders of magnitude faster.
The reason TLS uses both is practical: asymmetric encryption like RSA or elliptic curve cryptography is computationally expensive. Encrypting gigabytes of data with it would be prohibitively slow. Instead, TLS uses asymmetric cryptography only to securely agree on a symmetric session key. Once both sides have that shared key, all subsequent data is encrypted with fast symmetric algorithms like AES-GCM or ChaCha20-Poly1305.
The TLS Handshake Step by Step
The TLS handshake occurs after the TCP connection is established but before any application data is sent. In TLS 1.3, the handshake takes one round trip:
- Client Hello: The client sends a
ClientHellomessage containing the TLS version it supports, a list of cipher suites it can use, a random nonce, and its key share — the client's side of an ephemeral Diffie-Hellman key exchange. - Server Hello: The server responds with a
ServerHelloselecting the TLS version and cipher suite, its own key share, and its certificate. Using the two key shares, both sides can now independently compute the same shared secret — the Diffie-Hellman handshake. No secret was ever transmitted over the network. - Certificate verification: The client verifies the server's certificate: it checks the signature chain back to a trusted Certificate Authority, verifies the domain name matches, and confirms the certificate has not expired.
- Handshake complete: Both sides derive symmetric session keys from the shared secret and their random nonces. The server sends a
Finishedmessage encrypted with those keys. The client verifies it, sends its ownFinished, and the connection is ready for encrypted application data.
In TLS 1.2, this process took two round trips. TLS 1.3 reduced it to one by combining the key share into the first message, making HTTPS connections noticeably faster on high-latency connections.
TLS 1.2 vs TLS 1.3
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake round trips | 2 RTT | 1 RTT (0-RTT for resumption) |
| Cipher suites | Many, including weak ones | Five strong suites only |
| Forward secrecy | Optional (depends on cipher suite) | Mandatory (ephemeral key exchange always) |
| 0-RTT resumption | No | Yes (with replay risk for non-idempotent requests) |
| Deprecated algorithms | RC4, MD5, SHA-1 allowed in some suites | All weak algorithms removed |
What Certificates Actually Prove
A TLS certificate is a digitally signed document that binds a public key to a domain name (and optionally an organization). The signature is made by a Certificate Authority (CA) — an entity that both the client and server trust. Your browser ships with a list of approximately 150 trusted root CAs built in.
When the server presents its certificate, the client checks three things: the CA's signature is valid (proving the certificate was issued by a trusted authority), the domain name in the certificate matches the domain you requested (proving you reached the right server), and the certificate has not expired (proving it has not been revoked and replaced).
What a certificate does not prove is that the organization behind the domain is honest, legitimate, or who they claim to be. A certificate only proves domain ownership. Domain Validation (DV) certificates — the kind issued for free by Let's Encrypt — only verify that the applicant controls the domain. Organization Validation (OV) and Extended Validation (EV) certificates verify the organization's legal identity as well, but these distinctions are largely invisible to users in modern browsers.
Certificate Authorities and the Chain of Trust
CAs are organized in a hierarchy. Root CAs are the ultimate trust anchors, with their public keys embedded in browsers and operating systems. Because root private keys are extraordinarily sensitive, root CAs do not issue certificates directly to websites. Instead, they sign intermediate CA certificates, which in turn sign end-entity certificates for domains.
When a server presents its certificate, it typically also sends the intermediate CA certificates in the chain. The client verifies each link: the domain certificate is signed by the intermediate, the intermediate is signed by a root, and the root is in the client's trust store. This is the chain of trust. A single broken link — an expired intermediate, a revoked root, a signature mismatch — causes the TLS handshake to fail with a certificate error.
Certificate revocation handles the case where a private key is compromised before the certificate expires. CAs maintain Certificate Revocation Lists (CRLs) and operate OCSP (Online Certificate Status Protocol) servers that clients can query to check whether a certificate has been revoked. Modern browsers also use OCSP stapling — where the server fetches and includes a fresh OCSP response in the handshake — to speed up revocation checking without requiring a separate network request from the client.
Frequently Asked Questions
What does TLS stand for?
TLS stands for Transport Layer Security. It is the cryptographic protocol that secures HTTPS connections, encrypting traffic between a client and server. TLS evolved from SSL (Secure Sockets Layer), which was developed by Netscape in the 1990s. SSL is now deprecated; TLS 1.2 and TLS 1.3 are the versions in active use.
Is TLS the same as SSL?
No, though they are closely related. SSL was the original protocol, deprecated due to security vulnerabilities. TLS is its successor and replacement. The terms are often used interchangeably in conversation and in product names like "SSL certificates," but technically all modern secure connections use TLS. SSL 3.0, TLS 1.0, and TLS 1.1 are all disabled in modern browsers.
What is a TLS certificate?
A TLS certificate is a digital document that binds a public key to a domain name, signed by a Certificate Authority both parties trust. During the handshake, the server presents its certificate so the client can verify it is talking to the legitimate owner of that domain. Certificates have an expiration date and must be renewed periodically.
What is forward secrecy?
Forward secrecy means that compromising a server's long-term private key does not expose past session traffic. It is achieved using ephemeral key exchange algorithms like ECDHE that generate a fresh temporary key pair for each session. Even if an attacker records encrypted traffic today and later obtains the private key, they cannot decrypt those past sessions because the ephemeral session keys were discarded after use.
How do I check which TLS version a site uses?
Open your browser's developer tools, go to the Security tab, and look for the connection details. Chrome DevTools shows the protocol, key exchange, and cipher suite for the current connection. You can also use online tools like SSL Labs' Server Test to get a detailed report on a site's TLS configuration.
What happens if a TLS certificate expires?
When a TLS certificate expires, browsers display a prominent warning page blocking access and telling the user the connection is not private. The connection itself still encrypts traffic, but the authentication guarantee is broken — the client can no longer verify it is talking to the legitimate server. Site operators must renew and replace certificates before expiration to avoid interruption.