SSL and TLS: How Website Encryption Works

SSL and TLS

SSL and TLS are the encryption protocols that power the padlock in your browser. They secure the connection between your browser and a web server, protecting your data from interception, tampering, and impersonation. Every HTTPS connection you make relies on TLS to keep your passwords, payment details, and private communications safe in transit.

What Is SSL

SSL (Secure Sockets Layer) was the original encrypted communication protocol developed by Netscape in 1995. It was created to solve a critical problem with the early web: HTTP transmitted everything in plain text, meaning anyone who could intercept network traffic between a browser and a server could read passwords, credit card numbers, and private messages without any difficulty.

SSL created an encrypted tunnel between client and server that protected data in transit. However, as cryptographic research advanced, serious vulnerabilities were discovered in every version of SSL. SSL 2.0 was found to have fundamental design flaws within a year of release. SSL 3.0, released in 1996, survived longer but was ultimately broken by the POODLE attack discovered in 2014. All versions of SSL are now deprecated and disabled in every modern browser and server configuration.

What Is TLS

TLS (Transport Layer Security) is the modern, secure successor to SSL. It was first defined in RFC 2246 in 1999 and has been revised and strengthened multiple times since. TLS 1.2, released in 2008, remains widely deployed. TLS 1.3, released in 2018, is the current standard and introduces significant security and performance improvements over all previous versions.

Despite SSL being entirely obsolete, the term "SSL certificate" persists in everyday usage and in the names of hosting control panels, certificate vendors, and developer tools. When someone says "SSL" in a modern context, they always mean TLS. The two terms are used interchangeably in practice even though SSL itself has not been relevant for many years. The technically accurate term is TLS, but you will encounter SSL used as a synonym throughout the industry.

SSL vs TLS: Version History and Differences

How TLS Works: The Handshake

Before any encrypted data can be exchanged, the browser and server must complete a TLS handshake. This process authenticates the server, negotiates the encryption parameters, and establishes the shared session key that will be used to encrypt all subsequent communication. Understanding the handshake explains both why HTTPS is secure and why the first connection to an HTTPS site takes slightly longer than subsequent ones.

1. The browser connects to the server on port 443 and sends a ClientHello message listing the TLS versions and cipher suites it supports, along with a random value
2. The server responds with a ServerHello selecting the TLS version and cipher suite, sends its TLS certificate, and its own random value
3. The browser verifies the certificate against its list of trusted Certificate Authorities, checks that it has not expired, checks that it has not been revoked, and confirms it was issued for the correct domain
4. The browser and server perform a key exchange using an asymmetric algorithm such as ECDH to derive a shared session key without transmitting it over the network
5. Both sides confirm the handshake is complete and switch to symmetric encryption using the derived session key
6. All subsequent HTTP data in the session is encrypted with that shared key using a symmetric algorithm such as AES-256-GCM or ChaCha20-Poly1305

Browser                                    Server
  |                                           |
  |--- ClientHello (supported ciphers) ------>|
  |    + Key share (ECDH public key)          |
  |                                           |
  |<-- ServerHello (chosen cipher) -----------|
  |    + Key share (server ECDH public key)   |
  |    + Certificate                          |
  |    + Certificate Verify (signature)       |
  |    + Finished                             |
  |                                           |
  |--- Finished ---------------------------- >|
  |                                           |
  |<====== All data encrypted with AES ======>|
  |                                           |
  TLS 1.3 completes in 1 round trip (1-RTT)
  TLS 1.2 required 2 round trips (2-RTT)

What Is a TLS Certificate

A TLS certificate is a digital document that proves the identity of a website and contains the public key used during the handshake. Certificates are issued and signed by trusted third parties called Certificate Authorities (CAs). When your browser verifies a certificate, it checks that the CA that signed it is in its list of trusted authorities, that the certificate has not expired, that it has not been revoked, and that the domain name on the certificate matches the domain you are visiting.

Certificates contain several important pieces of information: the domain name or names they cover, the name of the organisation if applicable, the public key, the CA that issued them, the validity period, and a digital signature from the CA that allows browsers to verify the certificate has not been tampered with. The CA's signature is what makes the certificate trustworthy. Anyone can generate a self-signed certificate, but browsers only trust certificates signed by CAs in their pre-installed trust store.

Certificate Authorities and the Chain of Trust

Certificate Authorities form a hierarchy called the chain of trust. At the top are root CAs whose certificates are pre-installed in operating systems and browsers as trusted anchors. These root CAs typically do not issue certificates directly to websites. Instead, they sign intermediate CA certificates, which in turn sign the end-entity certificates used by websites. This chain means that to trust a website's certificate, the browser must be able to trace an unbroken chain of signatures from the website's certificate back to a trusted root CA.

Let's Encrypt is a free, automated, and widely trusted CA that has dramatically lowered the barrier to HTTPS adoption. It issues domain-validated certificates that are trusted by all major browsers and operating systems, automates the issuance and renewal process through the ACME protocol, and most major hosting platforms and web servers support automatic Let's Encrypt certificate provisioning. There is no longer any technical or financial reason for any public website to serve HTTP rather than HTTPS.

Root CA (pre-installed in browser/OS trust store)
  └── Intermediate CA (signed by Root CA)
        └── Website Certificate: example.com (signed by Intermediate CA)

Browser verification:
  1. Is example.com certificate signed by a trusted intermediate?   ✓
  2. Is the intermediate certificate signed by a trusted root CA?   ✓
  3. Is the root CA in the browser's trust store?                   ✓
  4. Has any certificate in the chain expired or been revoked?      ✓
  → Certificate is valid. Connection proceeds securely.

Configuring TLS on Your Server

Having a valid certificate is only part of secure TLS configuration. The cipher suites, protocol versions, and other settings your server advertises during the handshake determine how strong the actual encryption is. A poorly configured server might have a valid certificate but still be vulnerable to downgrade attacks or weak cipher negotiations.

• Disable TLS 1.0 and TLS 1.1: These versions are deprecated and should be disabled in your server configuration. Only TLS 1.2 and TLS 1.3 should be enabled.
• Enable TLS 1.3: All major web servers including Nginx, Apache, and Caddy support TLS 1.3. Enable it alongside TLS 1.2 for clients that do not yet support 1.3.
• Use strong cipher suites: Disable weak or export-grade ciphers. Use forward-secret cipher suites based on ECDH key exchange. Tools like Mozilla's SSL Configuration Generator provide server-specific configuration recommendations.
• Enable HTTP Strict Transport Security (HSTS): The Strict-Transport-Security header instructs browsers to only connect to your domain over HTTPS, even if the user types an HTTP URL, preventing SSL stripping attacks.
• Automate certificate renewal: Let's Encrypt certificates expire after 90 days. Tools like Certbot automate renewal and reload the server configuration automatically.
• Check your configuration: Tools like SSL Labs Server Test at ssllabs.com provide a free, detailed analysis of your server's TLS configuration and grade it from A to F.

Frequently Asked Questions

1. Is SSL free?
   Yes, for domain-validated certificates. Let's Encrypt provides free, automatically renewing DV certificates that are trusted by all major browsers and operating systems. Most hosting providers including Cloudflare, Netlify, Vercel, and major web hosts provision Let's Encrypt certificates automatically when you connect a domain. Paid certificates from commercial CAs provide organisation validation and extended validation, but the encryption strength is identical to a free DV certificate. For the vast majority of websites, a free Let's Encrypt certificate is entirely appropriate.
2. Does HTTPS improve SEO?
   Yes. Google announced HTTPS as a ranking signal in 2014 and has strengthened its preference for HTTPS over time. Chrome and other browsers display a "Not Secure" warning for any HTTP page that contains a form input, which can directly reduce user trust and increase bounce rates. Beyond the ranking signal, HTTPS prevents third parties such as ISPs and network operators from injecting content into your pages or intercepting form submissions, protecting your users and the integrity of your site's content. There is no reason not to use HTTPS for any public website in the current environment.
3. What happens when a TLS certificate expires?
   The browser displays a prominent security warning, typically "Your connection is not private" or "Certificate Error", and blocks users from reaching the site by default. Users can manually click through the warning in most browsers, but most will not, and the warning significantly damages user trust. For business sites, an expired certificate can effectively take the site offline from the perspective of ordinary users. Let's Encrypt certificates expire after 90 days by design to encourage automation. Tools like Certbot renew them automatically 30 days before expiry, ensuring the certificate never actually expires in a properly configured deployment.
4. What is Perfect Forward Secrecy and why does TLS 1.3 make it mandatory?
   Perfect Forward Secrecy (PFS) means that the compromise of a server's long-term private key does not expose past encrypted sessions. Without PFS, an attacker who records encrypted traffic today could decrypt all of it if they later obtain the server's private key through a breach or legal compulsion. With PFS, each session uses fresh temporary key pairs that are discarded after the session ends. Even with the private key, past sessions cannot be decrypted. TLS 1.3 makes PFS mandatory by requiring ephemeral key exchange algorithms for all connections, meaning every TLS 1.3 session benefits from this protection by default without any additional configuration.
5. What is the difference between a self-signed certificate and a CA-signed certificate?
   A self-signed certificate is one where the issuer and the subject are the same entity. Anyone can generate one with a single command, and it provides the same level of encryption as a CA-signed certificate. The difference is trust. Browsers maintain a pre-installed list of trusted Certificate Authorities. A certificate signed by one of these CAs is automatically trusted. A self-signed certificate is not in any trust store, so browsers display a prominent security warning when they encounter one. Self-signed certificates are appropriate for internal development environments and private networks where you control all the clients and can manually install the certificate as trusted. They are never appropriate for public-facing websites where users have no way to verify the certificate's legitimacy.

Conclusion

TLS, commonly referred to as SSL, is the foundation of secure communication on the web. It authenticates servers through the certificate chain of trust, encrypts data in transit using hybrid asymmetric and symmetric cryptography, and ensures the integrity of every byte exchanged between a browser and a server. TLS 1.3 is the current gold standard, offering faster handshakes, mandatory Perfect Forward Secrecy, and a simplified cipher suite that eliminates the weak options that plagued earlier versions. Every public website should be served over HTTPS with a valid certificate, which is now free and automatically managed through Let's Encrypt. Understanding TLS gives you the knowledge to configure servers securely, choose the right certificate for your use case, and protect your users' data throughout its journey across the internet. Continue with HTTP vs HTTPS, HTTP security headers, and symmetric vs asymmetric encryption to build a complete picture of web security.