What Is SSL/TLS? Encryption for the Modern Web

SSL and TLS: Understanding the Difference

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that provide secure communication over a network. You've seen their most visible manifestation every time you visit a website beginning with "https://" — the 's' stands for the security layer these protocols provide.

Despite SSL being the term most people use, SSL is technically obsolete and has been deprecated since 2015. SSL 3.0 (the last version) was found to be fundamentally insecure due to the POODLE vulnerability. TLS 1.0 and 1.1 were subsequently deprecated. The current standard is TLS 1.3, released in 2018, which offers significant performance and security improvements over its predecessors. TLS 1.2 remains widely supported and is acceptable; TLS 1.0 and below should be disabled entirely.

The distinction matters practically: if a server offers SSL 3.0 or TLS 1.0, it can be attacked using known vulnerabilities (POODLE, BEAST, FREAK). Use a HTTP headers check to verify which TLS versions a server offers and whether it's enforcing modern minimum versions.

TLS provides three core security properties:

• Confidentiality: Data is encrypted; eavesdroppers see only ciphertext
• Integrity: Message authentication codes (MACs) detect tampering
• Authentication: Certificates verify the server's identity (and optionally the client's)

The TLS Handshake Explained

Before any encrypted data flows, a TLS handshake establishes the session parameters. Understanding this process reveals both why TLS is secure and where it can be attacked.

TLS 1.3 Handshake (simplified):

1. ClientHello: The client sends supported cipher suites, TLS version, and a random nonce
2. ServerHello: The server selects a cipher suite and sends its certificate
3. Key exchange: Both parties use the Diffie-Hellman algorithm to derive a shared secret without transmitting it over the network — this provides "perfect forward secrecy"
4. Certificate verification: The client verifies the server's certificate is signed by a trusted CA and hasn't expired or been revoked
5. Session keys derived: Both sides independently derive the same symmetric encryption key from the shared secret
6. Handshake complete: All subsequent data is encrypted with the symmetric key

TLS 1.3 reduced the handshake to 1 round trip (down from 2 in TLS 1.2), cutting latency. For resumed sessions it supports 0-RTT (zero round-trip) resumption, though this has specific replay-attack considerations.

The cipher suite negotiated determines the algorithms used: key exchange (ECDHE), authentication (RSA or ECDSA), bulk encryption (AES-256-GCM), and hash (SHA-384). TLS 1.3 removed weak cipher suites entirely, preventing negotiation downgrade attacks.

SSL/TLS Certificates: How They Work

A TLS certificate is a digital document that binds a public key to an identity (domain name, organization). When your browser connects to a server, the server presents its certificate. The browser verifies the certificate's digital signature against a list of trusted Certificate Authorities (CAs) built into the operating system and browser.

Certificate types vary by validation level:

• Domain Validated (DV): Cheapest and most common. Verifies only that the requester controls the domain via DNS or HTTP challenge. Let's Encrypt issues free DV certificates. Adequate for encrypting traffic but provides no organizational identity verification.
• Organization Validated (OV): CA manually verifies the organization's legal existence. Shows org name in certificate details. Better for business sites where organizational identity matters.
• Extended Validation (EV): Rigorous manual verification of legal, operational, and physical existence. Historically showed org name in the browser address bar (green bar). Modern browsers have reduced visual differentiation, diminishing EV's user-facing value, though it remains useful for high-assurance use cases.

Certificate validity periods have been shortened dramatically for security reasons. As of 2024, publicly trusted certificates are limited to 398 days. Industry proposals would reduce this to 90 days or even 47 days, forcing more frequent renewal and reducing the window for compromised certificates to remain valid.

Certificate Transparency (CT) logs are append-only public records of every certificate issued by participating CAs. This enables detection of misissued certificates — if an attacker tricks a CA into issuing a certificate for a domain they don't own, it appears in the CT log where the domain owner can monitor it.

Common SSL/TLS Vulnerabilities and Misconfigurations

Even correctly implemented TLS can be undermined by configuration mistakes. The most common issues found in production environments:

Mixed content occurs when an HTTPS page loads resources (images, scripts, stylesheets) over HTTP. Modern browsers block active mixed content (scripts/iframes) but may load passive content, creating partial encryption that leaks data. A headers check will reveal whether your Content-Security-Policy prevents mixed content.

Weak cipher suites like RC4, 3DES, and export-grade encryption should be disabled. SSL Labs' server test grades configurations and identifies weak ciphers. A server still offering TLS_RSA_WITH_RC4_128_MD5 is vulnerable to attacks despite supporting TLS in general.

Missing HSTS (HTTP Strict Transport Security) allows SSL stripping attacks on first connections. HSTS tells browsers to always use HTTPS for the domain, even if the user types plain HTTP. HSTS preloading — submitting your domain to browsers' built-in HSTS lists — protects even the first connection.

Certificate chain issues occur when intermediate certificates are missing from the server's configuration. The client can't verify the chain back to the root CA, causing connection failures for some users. Always include the full chain in your server configuration.

Certificate expiration is embarrassingly common even in major organizations. Automated certificate management (ACME protocol, used by Let's Encrypt, Certbot, and cloud providers) eliminates this risk. Monitor certificate expiration with alerting at 30, 14, and 7 days remaining.

Implementing TLS: Best Practices for Websites

Getting HTTPS right requires attention to both certificate management and server configuration. Start by obtaining a certificate — Let's Encrypt provides free, automatically renewable DV certificates. For businesses, paid OV certificates from DigiCert, Sectigo, or GlobalSign add organizational verification.

Configure your server to use TLS 1.2 and 1.3 only. Disable SSLv3, TLS 1.0, and TLS 1.1. Enable only strong cipher suites with forward secrecy (ECDHE key exchange). Mozilla's SSL Configuration Generator produces ready-to-use configurations for Apache, Nginx, HAProxy, and other servers at ssl-config.mozilla.org.

Set these critical HTTP security headers:

• Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
• X-Frame-Options: DENY or SAMEORIGIN to prevent clickjacking
• X-Content-Type-Options: nosniff to prevent MIME sniffing
• Content-Security-Policy to prevent XSS and mixed content

Test your configuration using SSL Labs Server Test (ssllabs.com/ssltest) which provides an A-F grade with detailed findings. Aim for A+ rating. Use our headers check tool to verify your security headers are deployed correctly. Set up automated certificate monitoring and renewal to prevent expiration incidents.

Frequently Asked Questions