SSL and TLS Explained: Certificates, Handshakes, Protocol Versions and Cipher Suites

TLS, Transport Layer Security, is the protocol behind the padlock. It encrypts data between a browser and a server, detects tampering in transit, and, through a certificate, proves the server is who it claims to be. SSL is its obsolete predecessor; every SSL version is broken, so in practice the padlock always means TLS.

Understanding TLS pays off when you read a scan report, because most transport findings are variations on three questions: is the certificate trustworthy, is the protocol version current, and are the ciphers strong. Get those three right and the padlock means what users think it means.

What TLS actually provides

TLS delivers three guarantees, and it is worth separating them:

• Confidentiality — a network observer sees ciphertext, not your data.
• Integrity — any modification in transit is detected and the connection fails.
• Authentication — the certificate proves the server's identity, so you are not encrypting a conversation with an impostor.

The third is the one people forget. Encryption without authentication just means you are securely talking to someone; the certificate is what makes it the right someone.

What a certificate proves (and does not)

A TLS certificate binds a public key to a domain name, signed by a Certificate Authority the browser trusts. When you connect, the server presents the certificate and proves it holds the matching private key. The browser checks that the certificate is signed by a trusted CA, that it covers the hostname you asked for, and that it is within its validity dates.

The common certificate errors, expired, hostname mismatch, self-signed, untrusted chain, each have a specific cause and fix, covered in TLS certificate errors explained.

The handshake, step by step

Before any data flows, the two sides negotiate:

1. ClientHello. The browser offers its supported TLS versions, cipher suites and extensions.
2. ServerHello and certificate. The server picks the highest mutually supported version and a cipher suite, and sends its certificate chain.
3. Key agreement. Using ephemeral Diffie-Hellman (ECDHE), both sides derive a shared session key that a later compromise of the server's private key cannot recover. This property is forward secrecy.
4. Finished. Both confirm the handshake was not tampered with, and encrypted application data begins.

TLS 1.3 streamlined this to a single round trip and removed the older, riskier key-exchange options, which is why it is both faster and safer. It dropped static RSA key exchange, which lacked forward secrecy, along with a long list of legacy ciphers and compression that had enabled real attacks. The result is a protocol with far fewer ways to misconfigure it: where TLS 1.2 gives you enough rope to assemble a weak but technically valid setup, TLS 1.3 largely refuses to. That narrowing of choices is a security feature in itself.

The handshake also carries the machinery of trust beyond the certificate itself. Server Name Indication (SNI) tells the server which hostname you want, so one IP can serve many sites, and it is why a mismatched certificate on a shared host is a configuration error rather than an attack. OCSP stapling lets the server attach a fresh, signed proof that its certificate has not been revoked, sparing the browser a slow, privacy-leaking side trip to the CA. And Certificate Transparency logs, which browsers now expect certificates to appear in, make mis-issuance detectable after the fact. None of these is something you configure daily, but each is part of why a modern TLS connection is trustworthy, and each can surface in a detailed scan.

Protocol versions: what to serve in 2026

RFC 8996 formally deprecated TLS 1.0 and 1.1 in March 2021, and major browsers removed support around 2020. Serving them today gains you almost no real users and exposes you to downgrade attacks. Our deprecated-versions check flags them, and the TLS 1.3 check confirms the modern version is available.

Cipher suites, briefly

A cipher suite is the bundle of algorithms chosen during the handshake. A TLS 1.2 suite names four parts; TLS 1.3 simplified the list dramatically. Read one like this:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
       |      |        |         |
   key exch.  auth   encryption  integrity

You want ECDHE for forward secrecy, AES-GCM or ChaCha20-Poly1305 for authenticated encryption, and no RC4, 3DES, CBC-mode-with-known-issues or export ciphers. Weak or legacy suites are reported by our weak-ciphers check. The names look intimidating, but you rarely need to reason about individual suites; you need to serve a vetted list and exclude the known-bad families, which a generated configuration does for you.

Why do weak ciphers still appear on real servers in 2026? Almost always because a configuration was written years ago to support a browser that no longer exists and never revisited. Ciphers thought strong in 2014, RC4 was once a recommended defence against a different attack, became liabilities as cryptanalysis advanced. This is the core lesson of transport security: it is not "set once," it is "set, then re-check periodically," because the definition of strong moves. A server that was A-grade three years ago can quietly slip to a C simply by standing still while the rest of the field moves forward.

A known-good configuration

Mozilla's "intermediate" profile is a sound default for general audiences. In nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

TLS 1.3 negotiates its own ciphers, so the list above governs the TLS 1.2 fallback. Note ssl_prefer_server_ciphers off: with modern clients it is fine, and often better, to let the client pick from the strong set.

What a scanner checks and why

A transport scan looks at the whole chain of trust and configuration: is HTTPS available, does the certificate validate against the hostname, when does it expire, is the key strong enough (2048-bit RSA or 256-bit ECDSA and above), are deprecated protocols or weak ciphers offered, and is HSTS present to enforce all of it. Each answer is objective and observable, which is why passive scanning handles transport so well.

Run the SSL/TLS checker for a detailed protocol and cipher report, or the full website scanner to see transport alongside headers and cookies. Then lock the result in place with HSTS, and make sure users benefit from it via HTTPS-Only mode. Transport is the foundation the rest of the website security hub builds on.

It is reasonable to ask how much any of this still matters when browsers have made HTTPS the default and free certificates are universal. The answer is that the baseline has risen but the ceiling has not disappeared. Getting a certificate is trivial now; getting the configuration right is where sites still differ. The common 2026 findings are not "no HTTPS at all" but the subtler ones, a deprecated protocol left enabled for a browser that no longer exists, a cipher list copied from an old guide, a missing intermediate that fails intermittently, an HSTS header that forgot includeSubDomains, a certificate that will lapse because its renewal was never automated. These are exactly the issues a transport scan surfaces, and they are precisely the ones that do not announce themselves in day-to-day use. A green padlock tells a visitor the connection is encrypted; it does not tell them whether the encryption is strong, current and correctly enforced. That gap between "has HTTPS" and "has good HTTPS" is the whole reason transport scanning still earns its place. The reassuring part is that, unlike much of security, transport has a well-defined right answer: current protocol versions, a vetted cipher list, a valid and monitored certificate, and HSTS to enforce it all. Reach that state, re-check it a couple of times a year, and transport stops being something you worry about and becomes something you simply maintain. That is a rare and welcome thing in security: a problem with a clear finish line, a repeatable check to confirm you are still behind it, and no attacker ingenuity that can move the line once you have the configuration right and keep it current.