SSL vs TLS — What's the Difference?

SSL was developed by Netscape in 1994 to secure communications between web browsers and servers. SSL 1.0 was never publicly released due to serious security flaws discovered internally. SSL 2.0 shipped in Netscape Navigator 1.1 in 1995 but was quickly found to have fundamental weaknesses: it was vulnerable to man-in-the-middle attacks on cipher negotiation, used weak MAC construction, and lacked protection against session renegotiation attacks. SSL 3.0 (1996) fixed these issues but remained vulnerable to the POODLE attack discovered in 2014.

TLS 1.0 was published as RFC 2246 in 1999. It was essentially SSL 3.1 with minor improvements — close enough that SSL 3.0 and TLS 1.0 could interoperate with a fallback mechanism. TLS 1.1 (RFC 4346, 2006) added protection against CBC mode attacks. TLS 1.2 (RFC 5246, 2008) introduced support for SHA-256, authenticated encryption (AEAD) cipher suites, and removed weak legacy ciphers. TLS 1.2 remained the dominant version for over a decade.

TLS 1.3 (RFC 8446, 2018) was a major redesign. It eliminated all cipher suites not using forward secrecy, removed RSA key exchange entirely, reduced the handshake from two round trips to one (with a zero-RTT mode for resumed connections), and dropped support for all older, weaker cryptographic primitives. As of 2024, TLS 1.3 accounts for the majority of HTTPS connections on the web. SSL 3.0, TLS 1.0, and TLS 1.1 are now disabled by all major browsers and are rejected by most modern servers.

Before any encrypted application data is exchanged, the client and server perform a TLS handshake to agree on protocol version, cipher suite, and exchange keys. In TLS 1.2, the handshake requires two round trips: the client sends a ClientHello listing supported versions and cipher suites; the server responds with its chosen version, cipher suite, and certificate; the client verifies the certificate and sends key exchange data; the server completes the key exchange; both parties derive the session keys and signal that subsequent messages are encrypted.

TLS 1.3 streamlines this to one round trip. The ClientHello includes not just supported versions and cipher suites but also key exchange data (Diffie-Hellman key shares) for the most likely cipher suites. The server can immediately respond with its own key share, completing the Diffie-Hellman exchange in the same flight and deriving session keys without waiting for another round trip. This saves 60–100ms on a typical connection — meaningful for high-latency links and page load performance.

Zero-RTT (0-RTT) mode in TLS 1.3 allows a client to send application data in the first message of a resumed connection, eliminating the handshake entirely for known servers. The client uses a session ticket from a previous connection to encrypt the early data. 0-RTT data is inherently vulnerable to replay attacks (an attacker could retransmit the captured early data), so it should only be used for idempotent requests. Most HTTPS servers enable 0-RTT only for GET requests.

An SSL certificate (more accurately, a TLS certificate or X.509 certificate) is a digitally signed document that binds a public key to an identity — typically a domain name and, for EV certificates, an organization name. The certificate is signed by a Certificate Authority (CA) whose root certificate is pre-installed in operating systems and browsers as a trusted anchor. When your browser receives a server's certificate, it verifies the CA's signature, confirms the domain name matches, and checks that the certificate has not expired or been revoked.

Certificates contain: the domain name (Common Name or Subject Alternative Names), the public key, validity period (Not Before / Not After dates), the issuing CA's identity and signature, key usage extensions (what the key can be used for), and optionally an OCSP (Online Certificate Status Protocol) URL and CRL (Certificate Revocation List) distribution point for checking revocation. Modern certificates use SHA-256 or SHA-384 for the signature hash and RSA-2048+, ECDSA P-256, or ECDSA P-384 for the key pair.

The certificate's public key is used during the TLS handshake: in TLS 1.2, the client may encrypt a pre-master secret with the server's public key (RSA key exchange). In TLS 1.3, RSA key exchange is eliminated entirely — the certificate is used only for authentication (verifying the server's identity via a digital signature), while key agreement uses ephemeral Diffie-Hellman. This ensures forward secrecy: even if the server's private key is later compromised, past session keys derived from ephemeral DH cannot be reconstructed.

Domain Validation (DV) certificates are the most common type, accounting for the vast majority of HTTPS certificates on the web. A CA issues a DV certificate after verifying that the applicant controls the domain, either by serving a specific file at a known URL (HTTP-01 challenge), creating a specific DNS TXT record (DNS-01 challenge), or responding to a challenge via TLS-ALPN (TLS-ALPN-01 challenge). DV certificates are issued immediately, often within seconds via automated systems like Let's Encrypt. They prove domain control but nothing about the organization behind the domain.

Organization Validation (OV) certificates include the organization's name after the CA verifies it against business registries. Browsers do not prominently display OV details in the UI, making them primarily useful for internal audiences or contexts where the certificate details are inspected directly. Extended Validation (EV) certificates historically displayed the organization name in the browser address bar's green padlock — a highly visible trust signal. Most major browsers removed the EV display in 2019 because research showed users did not notice or act on it, and phishing sites were obtaining EV certificates for convincingly named legal entities.

Wildcard certificates (*.example.com) cover all subdomains at one level (blog.example.com, shop.example.com) but not sub-subdomains (a.b.example.com). They are efficient for organizations with many subdomains but present increased risk: if the private key is compromised, all subdomains are vulnerable. Multi-SAN (Subject Alternative Names) certificates list multiple specific domains in a single certificate — a more targeted alternative to wildcards for organizations serving multiple distinct domains from shared infrastructure.

The web's security model depends on a set of trusted root Certificate Authorities (CAs) — organizations whose root certificates are pre-installed in operating systems and browsers. As of 2024, major root stores (Mozilla NSS, Windows, macOS, Android) each trust approximately 100–150 root CAs. These root CAs typically do not sign subscriber certificates directly. Instead, they use intermediate (subordinate) CAs, which sign subscriber certificates. This creates a chain: root CA signs intermediate CA certificate, intermediate CA signs your server certificate. Your server sends both its certificate and the intermediate certificate(s) to allow the client to build and verify the chain to a trusted root.

The CA ecosystem has faced significant challenges. Diginotar, a Dutch CA, was compromised in 2011 and issued fraudulent certificates for *.google.com, which were used to perform man-in-the-middle attacks on Iranian Gmail users. Diginotar was subsequently removed from all root stores and went bankrupt. Symantec's CA business was distrusted by Google in 2018 after persistent mis-issuance. These incidents drove the development of Certificate Transparency (CT), an RFC 9162 standard that requires all certificates issued by trusted CAs to be logged in public append-only logs — making unauthorized certificate issuance visible and auditable.

Let's Encrypt, launched in 2016 by the Internet Security Research Group, provides free DV certificates via the ACME protocol, automated issuance, and 90-day expiry with automated renewal. It has become the world's largest CA by certificate count, dramatically lowering the barrier to HTTPS deployment. Certbot and similar ACME clients automate certificate issuance and renewal, making manual certificate management largely obsolete for standard web servers.

HTTPS is HTTP over TLS. The browser connects to port 443 (or a custom port), performs the TLS handshake, and then sends HTTP requests through the encrypted tunnel. From the application's perspective, HTTPS is identical to HTTP — the TLS layer is transparent. The 'padlock' icon in the browser address bar indicates that: (1) the connection is encrypted, and (2) the server's certificate was verified as trusted. It does not indicate that the website is safe, legitimate, or not phishing — only that the connection to whatever server you connected to is encrypted.

HSTS (HTTP Strict Transport Security) is a response header (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) that instructs browsers to connect only via HTTPS for the specified duration. Once a browser has seen an HSTS header, it refuses to make plain HTTP connections to the domain — automatically upgrading HTTP requests to HTTPS and refusing to connect if the certificate is invalid. HSTS prevents SSL stripping attacks, where an attacker downgrades a connection from HTTPS to HTTP. The preload directive allows sites to be hardcoded into browser HSTS preload lists, protecting first-time visitors.

Mixed content occurs when an HTTPS page loads subresources (images, scripts, stylesheets, iframes) over HTTP. Active mixed content (scripts, iframes) is blocked entirely by modern browsers — a HTTP script on an HTTPS page is never loaded. Passive mixed content (images, audio, video) generates a browser warning and is increasingly blocked. Mixed content breaks the security guarantee of HTTPS because an attacker who can intercept the HTTP subresource request can inject malicious code into the otherwise-encrypted page. The ${siteConfig.name} Header Checker tool can identify HSTS configuration and related security headers for any URL.

A cipher suite specifies the algorithms used for key exchange, authentication, bulk encryption, and message authentication in a TLS connection. In TLS 1.2, cipher suites were named like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 — ECDHE for key exchange, RSA for authentication, AES-256-GCM for encryption (authenticated encryption with associated data / AEAD), SHA-384 for the PRF. In TLS 1.3, cipher suite naming is simplified because key exchange is always ephemeral DH and authentication is always using the certificate — the cipher suite specifies only the AEAD algorithm and hash: TLS_AES_256_GCM_SHA384.

Forward secrecy (also called Perfect Forward Secrecy / PFS) means that session keys are derived from ephemeral key material — new random values for each connection — rather than from the server's long-term private key. If a server's private key is later stolen (from a data breach or compelled disclosure), the attacker cannot decrypt previously recorded TLS sessions because the ephemeral key material was discarded after the session ended. All TLS 1.3 cipher suites provide forward secrecy. TLS 1.2 cipher suites with RSA key exchange (where the client encrypts the pre-master secret with the server's public key) do not.

Server-side cipher suite configuration matters. Administrators should prioritize AEAD cipher suites with forward secrecy, disable 3DES, RC4, and NULL cipher suites, and ensure the server prefers strong ciphers rather than accepting whatever the client offers. Tools like ssllabs.com's SSL Test grade servers on cipher suite configuration. The ${siteConfig.name} SSL Checker provides a focused certificate validity and expiry check, verifying the chain of trust and key parameters.

TLS certificates have a limited validity period. As of September 2020, the maximum validity for publicly trusted certificates is 398 days (approximately 13 months). Let's Encrypt issues certificates with 90-day validity and encourages automated renewal. Short validity periods reduce the window of exposure if a certificate's private key is compromised — a shorter-lived certificate limits how long a leaked key can be used to impersonate a site.

When a certificate's private key is compromised before expiry, the CA revokes it. Revocation is communicated via two mechanisms: CRL (Certificate Revocation Lists) — periodic downloads of revoked serial numbers — and OCSP (Online Certificate Status Protocol) — real-time queries to the CA's OCSP responder. OCSP Stapling improves on basic OCSP by having the server periodically fetch a CA-signed OCSP response and 'staple' it to the TLS handshake, so clients receive revocation status without making a separate OCSP request to the CA.

In practice, browser revocation checking has significant limitations. Many browsers soft-fail on OCSP errors — if the OCSP responder is unreachable, the browser proceeds with the connection rather than blocking it, reducing revocation enforcement to a false sense of security in failure scenarios. CRLite and OneCRL are more robust approaches that batch revocation data into browser updates. Monitoring your certificate's expiry and replacing it before it expires is far more reliable than revocation — use the ${siteConfig.name} SSL Checker to track expiry dates.

TLS 1.3 represents the most significant redesign of the protocol since TLS 1.0. The changes fall into three categories: removal of insecure legacy features, simplification of the handshake, and improved default security. Removed features include: RSA and DH static key exchange (both lack forward secrecy), CBC mode cipher suites (vulnerable to padding oracle attacks like BEAST and Lucky 13), RC4 (cryptographically broken), MD5 and SHA-1 in signatures, compression (vulnerable to CRIME/BREACH), and renegotiation. What remains is a clean, modern protocol.

The simplified 1-RTT handshake reduces connection establishment time, benefiting latency-sensitive applications. 0-RTT resumes known connections with no handshake overhead at all, though with the replay attack caveat noted earlier. Session tickets replace session IDs for resumption, and the session ticket key itself should be rotated regularly to limit the forward secrecy window — a detail that some server configurations overlook.

TLS 1.3 is now deployed by default on all major browsers (Chrome, Firefox, Safari, Edge) and supported by all modern web server software (nginx, Apache, IIS, Caddy). Cloud providers and CDNs universally support it. If a server does not yet support TLS 1.3, it almost certainly has broader maintenance deficiencies — use the ${siteConfig.name} SSL Checker and the Link Checker to verify connectivity and certificate health as a first step in any web security audit.

Certificate expiry is one of the most common causes of unplanned HTTPS outages. A certificate that expires causes every browser to display a full-screen certificate error, effectively taking the site offline for most visitors. The VSPIC SSL Checker allows you to enter any domain and immediately see the certificate's expiry date, issuing CA, and validity status. For production sites, set up automated monitoring that alerts at 30 days and 7 days before expiry.

Beyond expiry, a correct TLS configuration requires: the full certificate chain (server certificate plus all intermediate certificates) is served, the certificate's Subject Alternative Names include all hostnames the server responds to, HSTS is configured with an appropriate max-age, and the server disables TLS 1.0 and 1.1. The DNS Lookup tool is useful for verifying CAA (Certification Authority Authorization) records — DNS records that specify which CAs are authorized to issue certificates for a domain, preventing unauthorized issuance.

WHOIS is a complementary check for certificate-related security: it reveals domain registration details that help verify the legitimacy of a certificate. If a certificate claims to represent a well-known organization but the domain was registered last week, that is a strong phishing indicator. Combining SSL Checker, DNS Lookup, and WHOIS Lookup provides a comprehensive view of a domain's security posture — exactly what is available at ${siteConfig.name}.

For new websites, use Let's Encrypt with automated ACME renewal (Certbot, acme.sh, or your hosting provider's built-in certificate management). Configure 90-day automatic renewal — certificates should be renewed at 60 days (30 days before expiry) to allow time to catch failures. Ensure your server software is configured to serve TLS 1.2 and 1.3 only, disabling TLS 1.0 and 1.1. Prioritize AEAD cipher suites with forward secrecy.

HTTP to HTTPS redirects should use 301 Permanent redirects (not 302 Temporary) so browsers and search engines update their cached URLs. Deploy an HSTS header immediately and increase the max-age progressively — start with max-age=86400 (1 day), then max-age=2592000 (30 days), then max-age=31536000 (1 year) with includeSubDomains once you are confident all subdomains are HTTPS. Only add the preload directive when you are certain you will never need to serve HTTP on this domain again, as removal from preload lists takes months.

Configure OCSP Stapling on your server to avoid OCSP privacy leaks and reduce connection latency. Add CAA DNS records specifying which CAs are authorized to issue certificates for your domain — this is a simple DNS change that prevents unauthorized issuance. Use the ${siteConfig.name} DNS Lookup tool to verify your CAA records are correctly configured. Finally, test your complete HTTPS configuration using SSL Checker after every certificate renewal and server configuration change to catch issues before they affect users.