Defaults.Exposed

Defaults.Exposed › Reports

SSL vs TLS

Published

SSL and TLS do the same job — encrypt the connection between a browser and a website so nobody in between can read or tamper with it — but they are different generations of the same protocol, and only one of them is still alive. TLS (Transport Layer Security) is the current standard. SSL (Secure Sockets Layer) is its deprecated predecessor, formally retired in 2015. The “SSL certificate” you buy, install, and renew is, technically, a TLS certificate: the label stuck while the protocol underneath it moved on. What actually matters is not the name but the state of your encryption — which TLS version your server negotiates, and whether your certificate is valid, unexpired, and trusted. The defaults.exposed August 2026 census evaluated TLS across 231,991,983 HTTPS-serving domains and found 5.2 million still serving expired certificates and 3.3 million serving self-signed ones: millions of sites whose owners believe they have “SSL” while their real TLS posture is broken.

If you have ever asked whether you need “SSL” or “TLS,” the honest answer is that you already have TLS if you have HTTPS at all — the question that matters is which version and in what condition. This guide untangles the two names, walks the version history from SSL 2.0 to TLS 1.3, and shows what the encryption layer really looks like at internet scale. The figures throughout come from the defaults.exposed August 2026 census, an independent scan of 432,127,908 domains graded as of 2026-08-16.

SSL vs TLS: same job, different generation

SSL and TLS are the same protocol at two points in its life. Both provide the same three guarantees for a network connection:

SSL was invented at Netscape in the mid-1990s to secure early web commerce. When the protocol was handed to the Internet Engineering Task Force (IETF) to become an open, vendor-neutral standard, it was renamed. TLS 1.0, published as RFC 2246 in 1999, is essentially “SSL 3.1” — the version number reset and the name changed to signal that the protocol no longer belonged to one company. Everything since has carried the TLS name.

So there is no technical rivalry between “SSL” and “TLS.” One did not beat the other in a contest. TLS is simply what SSL grew into, the way HTTP/2 is what HTTP became — a continuous line of successors, each fixing the flaws of the last. Every version of SSL is now deprecated and unsafe; the only versions you should be negotiating today are TLS 1.2 and TLS 1.3. How defaults.exposed grades the protocol version a server actually offers is set out in the TLS version methodology.

The practical upshot: when a hosting panel, a certificate vendor, or a colleague says “SSL,” they almost always mean TLS. The word survives out of habit, not accuracy.

Why everyone still says “SSL certificate”

The certificate is where the naming confusion is stickiest, so it is worth being precise: there is no such thing as an “SSL certificate” as distinct from a “TLS certificate.” They are the same object. A web certificate is an X.509 document (the format defined in RFC 5280) that binds a domain name to a public key and is signed by a certificate authority. It does not encode which protocol will be used. The very same certificate secures a TLS 1.3 connection and would have secured an SSL 3.0 connection — the protocol is negotiated fresh on every handshake, independently of the certificate.

The term “SSL certificate” persists for three reasons:

  1. Marketing inertia. Certificate authorities and resellers sold “SSL certificates” for two decades. Renaming the product every time the protocol advanced would have confused customers, so the brand name froze even as the technology moved.
  2. Control panels and tooling. Hosting dashboards, load-balancer settings, and CDN menus still label the feature “SSL.” The button says SSL; the bytes on the wire are TLS.
  3. The padlock lore. A generation of users learned “the padlock means SSL.” The padlock has meant TLS for years, but the mental model lags.

None of this is harmful on its own — calling it an SSL certificate is a venial sin. The harm comes when the outdated name masks an outdated posture: an owner who thinks “I have SSL, I’m secure” and never checks whether the certificate is expired, self-signed, or chained to a distrusted authority. A certificate only delivers trust if a browser accepts it, and that acceptance depends on the authority that signed it — see What Is a Certificate Authority? How Web Trust Works for how that chain is built and where it breaks.

The version timeline: SSL 2.0 to TLS 1.3

Six protocol versions have shipped in wide use. Only two are safe today. Knowing the timeline explains why “SSL” is a warning sign and “TLS 1.3” is a good sign.

The pattern is clear. Every version named “SSL” is deprecated and dangerous; TLS 1.0 and 1.1 have joined them; and the safe floor is TLS 1.2, with TLS 1.3 as the destination. When a scanner reports that your server still offers SSL 3.0 or TLS 1.0, that is not a naming quirk — it is a live weakness that lets an attacker attempt a downgrade to broken cryptography. The cipher suites that each protocol version permits are graded in the cipher strength methodology.

What changed in TLS 1.3 (speed and security)

TLS 1.3 is not a small revision of TLS 1.2 — it is a deliberate cull. The design philosophy was to remove every option that had ever been the root of an attack, leaving a protocol that is hard to configure insecurely. Four changes matter most.

A faster handshake. TLS 1.2 needs two round trips between client and server before any application data flows. TLS 1.3 completes the handshake in a single round trip (1-RTT), and for repeat visits it supports 0-RTT resumption, where the client can send data on its very first message. For the user, this is measurably faster page loads; for the operator, it is lower latency at no security cost.

Mandatory forward secrecy. In older versions, a server could use static RSA key exchange, meaning that if its private key were ever stolen, an attacker who had recorded past traffic could decrypt all of it retroactively. TLS 1.3 removes static key exchange entirely and mandates ephemeral Diffie-Hellman. Every session gets a fresh key that is discarded afterward, so a future key compromise cannot unlock yesterday’s recorded sessions.

A cull of weak cryptography. TLS 1.3 deleted the algorithms that caused the previous decade’s attacks: RC4, 3DES, CBC-mode ciphers, MD5 and SHA-1 signatures, and export-grade suites. It permits only AEAD cipher suites, which combine encryption and integrity in one vetted construction. There is simply no insecure cipher left to negotiate.

An encrypted handshake. More of the handshake itself is now encrypted, reducing what a passive observer can learn about the connection.

The combined effect is a protocol that is both quicker and safer, which is why adoption is worth measuring rather than assuming. TLS 1.3 uptake is uneven across the world — some country-code TLDs default their infrastructure to it, others lag well behind. The defaults.exposed twin analysis breaks this down registry by registry in TLS 1.3 by Country: Which TLDs Win on Defaults.

The real-world state of TLS certificates (census data)

Naming and version history are the theory. The census is the practice — and at internet scale, “SSL health” turns out to be a story of certificates that are present but broken.

Of the 432,127,908 domains scanned in August 2026, 231,991,983 served content over HTTPS and had their TLS layer evaluated. Within that population, the failures cluster in a few predictable places:

Both of these are certificates that exist. Their owners installed “SSL” and, in many cases, believe the job is done. It is not: a certificate delivers trust only while it is valid, unexpired, and signed by a trusted authority. Whether a served certificate meets that bar is graded in the certificate validity methodology, and the warning window before expiry is graded in the certificate expiry methodology.

The picture is worse one step earlier, before certificates enter the frame at all. 44 million domains serve no TLS whatsoever — plain HTTP only, with no encryption on the wire. A further 27 million answer on HTTP but never redirect to HTTPS, so even where a certificate exists, a first-time visitor arriving over http:// is served an unencrypted page and quietly stays there. That gap between “has a certificate” and “actually protects every visitor” is measured in the HTTPS availability methodology. It is one reason the census’s harshest grade is so common: 295,157,813 domains — about 78.3% of everything scanned — earn a grade of F once every check is applied.

The lesson for anyone thinking in “SSL” terms: the presence of a certificate is the start of the question, not the answer. Valid, unexpired, trusted, and enforced on every request is the bar — and millions of sites clear the first hurdle while failing the rest.

RSA vs ECDSA keys and 90-day lifetimes

Two quieter shifts are reshaping what a healthy certificate looks like, and both trip up owners who last thought about “SSL” a decade ago.

The key algorithm is migrating from RSA to ECDSA. For most of the web’s history, certificates used RSA keys, typically 2048 bits. Elliptic-curve cryptography (ECDSA) delivers equivalent security with far smaller keys — a 256-bit ECDSA key is roughly comparable in strength to a 3072-bit RSA key — which means faster handshakes and less CPU per connection. The migration is well underway but far from complete, and it is not a simple “newer is better” story: RSA remains secure at adequate key lengths, and many operators serve both to stay compatible with older clients. defaults.exposed measures where the web sits on this transition in RSA vs ECDSA in 2026: Measuring the Web’s Key Migration, and grades the key strength a certificate actually presents in the certificate key strength methodology. The algorithm used to sign the certificate is graded separately in the certificate signature algorithm methodology.

Certificate lifetimes are collapsing. The old world of three-year certificates is gone. A 90-day lifetime — popularised by automated authorities and free issuance — is now the norm, and the industry is moving toward even shorter windows over the next few years. Short lifetimes are a security win: a compromised or mis-issued certificate stops mattering quickly, and revocation becomes less critical when everything expires soon anyway. But they make one thing non-negotiable: automation. A 90-day certificate renewed by hand will eventually be forgotten, and forgotten renewals are precisely why 5.2 million domains are serving expired certificates right now. The shift and its operational demands are covered in The 90-Day Web: Certificate Lifetimes in 2026.

There is a related default worth knowing about: wildcard certificates, which cover *.yourdomain.com with a single key. They are convenient, but they concentrate risk — one compromised key exposes every subdomain — and they now cover 28.5% of the TLS web. If you inherited a wildcard because it was “easier,” it is worth understanding the trade-off, laid out in Wildcard Certificates: 28.5% of the TLS Web on One Key.

How to check which TLS version your site uses

You do not need to guess which protocol and certificate state your site presents — every part of it is observable from outside, exactly as an attacker or a customer’s browser would see it. There are three levels of effort.

The browser (30 seconds). Open your site, click the padlock, and view the connection details. Most browsers show the negotiated TLS version and the certificate’s issuer and expiry date directly. If you see TLS 1.3 or TLS 1.2 and a valid date, the basics are sound. If you see TLS 1.0 or a warning, you have found a problem.

The command line (for the precise answer). From any machine with OpenSSL installed:

openssl s_client -connect yourdomain.com:443 -tls1_3

If the handshake completes, your server supports TLS 1.3. Swap -tls1_2, -tls1_1, or -tls1 to test each version — a successful handshake on -tls1 or below is a finding to fix. The same output shows the full certificate chain, issuer, and validity dates.

A full scan (for the complete posture). The browser tells you about one connection; a scanner tells you about all of it at once — protocol versions offered, certificate validity and expiry, key type and strength, whether HTTP redirects to HTTPS, and whether HSTS is set (only 20.1% of the TLS web deploys HSTS, the header that forces browsers to use HTTPS on every future visit — graded in the HSTS methodology).

Check your domain free at defaults.exposed — it reads your live TLS configuration and certificate straight from your public endpoint and tells you which protocol versions you offer, whether your certificate is valid and unexpired, and where the gaps are. It takes about 30 seconds and needs no account.

What this means

For business owners, “SSL vs TLS” is a distraction from the only two questions that carry money: is my certificate valid right now, and does every visitor actually get an encrypted, trusted connection? An expired certificate greets your customers with a full-page browser warning that reads, in plain language, “this site may be dangerous” — and most people leave. With 5.2 million domains serving expired certificates and 3.3 million serving self-signed ones, this is not a rare edge case; it is a routine, self-inflicted outage. The fix is almost always automating renewal so a human can never forget it.

For IT and security teams, the terminology should be settled internally: you run TLS, you disable everything below TLS 1.2, and you treat “SSL” as a legacy label in tooling, not a protocol you support. The real work is configuration hygiene — no SSL 3.0 or TLS 1.0 offered, no expired or self-signed certificates in production, automated issuance and renewal, HTTP redirecting to HTTPS, and HSTS set so downgrade attacks have nothing to grab. Each of these is independently checkable and independently gradable, which means each can be turned into a monitored control rather than a thing someone remembers to look at.

For developers, the takeaway is that the certificate is protocol-agnostic and the protocol is negotiated per connection, so the two decisions are separate: pick your key type and issuance flow for the certificate, and pin your minimum protocol version and cipher policy on the server. Getting TLS 1.3 with forward secrecy is now mostly a matter of not overriding sane defaults — the danger is old config that still enables deprecated versions “for compatibility” long after the clients that needed them disappeared.

FAQ

Is SSL the same as TLS? Effectively yes — they are two generations of the same protocol, doing the same job: encrypting and authenticating a connection between a browser and a server. TLS is the direct successor to SSL, renamed in 1999 when the protocol became an open IETF standard rather than a Netscape product. TLS 1.0 is essentially “SSL 3.1.” The difference is that every version actually called SSL is now deprecated and insecure, while TLS 1.2 and TLS 1.3 are current. So when someone says “SSL” today, they almost always mean TLS. In the August 2026 census, defaults.exposed evaluated TLS across 231,991,983 HTTPS-serving domains — none of them should still be negotiating SSL.

What is the difference between SSL and TLS? The main differences are age and safety. SSL (versions 2.0 and 3.0) came from Netscape in the 1990s and is fully deprecated — SSL 2.0 was prohibited in 2011 and SSL 3.0 in 2015 after the POODLE attack. TLS is the standardised continuation: TLS 1.0 and 1.1 are also now deprecated (2021), leaving TLS 1.2 and TLS 1.3 as the safe versions. TLS 1.3 in particular removed all the weak ciphers and legacy key-exchange methods that made older versions attackable, and made handshakes faster. The certificate itself is identical across both — it is the protocol negotiated on each connection that differs. Practically, “the difference” is that TLS is what you should be running and SSL is what you should have turned off.

Is TLS more secure than SSL? Yes, unambiguously. Every version of SSL contains known, exploitable weaknesses and has been formally deprecated; SSL 3.0 fell to the POODLE attack in 2014 and was retired in 2015. TLS 1.2 and especially TLS 1.3 fixed those flaws — TLS 1.3 mandates forward secrecy, permits only strong AEAD cipher suites, and removes the downgrade paths that older versions left open. A server that still offers SSL 3.0 or TLS 1.0 alongside modern versions is not “extra compatible,” it is exposed, because an attacker can try to force a downgrade to the weakest option on offer. The census graded certificate and protocol posture across 231,991,983 HTTPS-serving domains, and offering deprecated protocols is one of the clearest fixable weaknesses. You can see where your own domain stands — Check your domain free at defaults.exposed.

Should I still use SSL? No. There is no version of SSL that is safe to use, and browsers stopped supporting it years ago, so a server offering only SSL cannot even complete a handshake with a modern client. If you have “SSL” enabled in a hosting panel or load balancer, understand that the label is legacy — the actual secure protocol is TLS, and what you want is TLS 1.2 as a minimum floor with TLS 1.3 preferred. The one action worth taking is to confirm your server does not still offer SSL 3.0 or TLS 1.0 for “compatibility,” and that your certificate is valid and unexpired. Among the 231,991,983 HTTPS-serving domains in the August 2026 census, 5.2 million were serving expired certificates — a reminder that having “SSL” configured once is not the same as being protected today.

Data to cite

See where your own domain stands

The SSL-versus-TLS debate has a simple resolution: you run TLS, and the only questions worth your attention are which version your server offers and whether your certificate is valid, unexpired, and trusted. Those are not questions you have to guess at — they are visible to every browser and every attacker, which means they are visible to you.

Check your domain free at defaults.exposed — it reads your live TLS configuration and certificate directly from your public endpoint and tells you the negotiated protocol versions, the certificate’s validity and expiry, the key type and strength, whether HTTP redirects to HTTPS, and whether HSTS is set. It takes 30 seconds and needs no account. If you want the gaps closed properly — deprecated protocols disabled, automated renewal so nothing ever expires, and a clean modern TLS configuration — see how the fix works.

Read the flagship census report: The State of Domain Security 2026 →

Related from this series: TLS 1.3 by Country: Which TLDs Win on Defaults · Expired SSL Certificates: 5.2 Million Sites Still Serving · Self-Signed Certificates: The 3.3 Million Domain Census · What Is a Certificate Authority?

Aggregate data only. Data stored and processed in the EU.

Data source: defaults.exposed August 2026 census, methodology v9, as of 2026-08-16. 432,127,908 domains scanned; 231,991,983 served content over HTTPS and had their TLS layer evaluated. All figures are counts of scanned domains. References: RFC 8446 (TLS 1.3), RFC 5246 (TLS 1.2), RFC 7568 (SSL 3.0 deprecation), RFC 6176 (SSL 2.0 prohibition), RFC 8996 (TLS 1.0/1.1 deprecation), RFC 5280 (X.509).

How to cite this report

Press / blog: defaults.exposed (2026). SSL vs TLS: What’s the Difference (and Which Do You Have)? defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/v9/articles/ssl-vs-tls

Academic: defaults.exposed. (2026, August 21). SSL vs TLS: What’s the Difference. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/v9/articles/ssl-vs-tls

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=231,991,983 HTTPS-serving domains)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 using methodology v9; 231,991,983 of them served content over HTTPS and had their TLS and certificate layer evaluated. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/v9/methodology Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026

Data sourced from the August 2026 grading methodology (v9) — 34 checks, 376 million domains. Browse the census statistics or the Census Explorer, or see all August 2026 research →