🤝Module 06 — The TLS Handshake, 1.2 vs 1.3

Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
Verify return code: 0 (ok)
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Verify return code: 0 (ok)

What to read out of this — five lines, and each is one of the three jobs.

• Protocol : TLSv1.3 — job 1. Both sides supported it, so it was chosen. Neither side was asked; the client offers, the server picks.
• Cipher : TLS_AES_256_GCM_SHA384 — also job 1. AES-256 in GCM mode, with SHA-384 for key derivation.
• Peer signature type: ECDSA — job 2. The server signed part of the handshake with its certificate's private key. Note the word signature: the certificate key signed, it did not encrypt.
• Server Temp Key: X25519, 253 bits — job 3, and the most important line here. "Temp" means ephemeral — a key pair generated for this connection and thrown away afterwards. It has nothing to do with the certificate.
• Verify return code: 0 (ok) — the chain validated, using everything from Module 05.

🔑 Server Temp Key is the forward-secrecy indicator. If that line is present, the session key came from an ephemeral Diffie-Hellman exchange, and stealing the server's certificate key later will not decrypt this traffic. If the line is absent on a TLS 1.2 connection, you are looking at RSA key transport and there is no forward secrecy — which is section C2.

Three jobs, in order: negotiate parameters, authenticate the server, agree a shared symmetric key.

In TLS 1.3 it is one round trip. The client sends a ClientHello containing its supported versions, cipher suites, and — crucially — a key share guessed in advance. The server replies with ServerHello (its own key share), and from that point everything is encrypted: EncryptedExtensions, its Certificate, a CertificateVerify signature proving it holds the matching private key, and Finished. The client verifies the chain, checks the signature, and sends its own Finished. Application data flows after 1-RTT.

In TLS 1.2 it is two round trips, because the client cannot send a key share until it learns which parameters the server chose.

The detail that separates a strong answer: the certificate's key is used only for a signature, never to encrypt the session key. Key agreement is a separate ephemeral Diffie-Hellman exchange — which is what gives forward secrecy, and why TLS 1.3 removed RSA key transport entirely.

>>> TLS 1.3, Handshake [length 013a], ClientHello
<<< TLS 1.3, Handshake [length 007a], ServerHello
<<< TLS 1.3, InnerContent [length 0001]
<<< TLS 1.3, Handshake [length 0006], EncryptedExtensions
<<< TLS 1.3, InnerContent [length 0001]
<<< TLS 1.3, Handshake [length 0982], Certificate
<<< TLS 1.3, InnerContent [length 0001]
<<< TLS 1.3, Handshake [length 004f], CertificateVerify
<<< TLS 1.3, InnerContent [length 0001]
<<< TLS 1.3, Handshake [length 0034], Finished
>>> TLS 1.3, ChangeCipherSpec [length 0001]
>>> TLS 1.3, Handshake [length 0034], Finished

What to read out of this — this is the diagram above, real.

• >>> is client→server, <<< is server→client. Count them: the client sends one message before the server's whole reply arrives. One round trip.
• Everything from EncryptedExtensions onward is encrypted. That is why each is preceded by InnerContent — TLS 1.3 wraps encrypted handshake records so that even the type of message is hidden. The certificate itself is encrypted on the wire, which is a genuine privacy improvement over 1.2: a passive observer cannot see which certificate the server presented.
• Certificate [length 0982] — 2,434 bytes. Look at that relative to ServerHello at 122 bytes. The certificate chain is the overwhelming bulk of a handshake, which is why chain length is a real performance figure (Module 05, A1.1) and why EC keys are worth using (Module 02, A1.1).
• CertificateVerify [length 004f] — 79 bytes. This is job 2, and it is the only place the certificate's private key is used. A signature over the entire handshake transcript so far, proving live possession of the key.
• ChangeCipherSpec is a fossil. TLS 1.3 does not need it — key changes are implied. It is sent purely so that middleboxes written for TLS 1.2 see something familiar and do not drop the connection. RFC 8446 calls this "compatibility mode", and it is a small monument to how much broken network equipment exists.

💡 -msg is the flag to remember. For even more detail, -trace decodes the contents of each message — verbose, but the best way to see exactly which extensions a client offered.

Server Temp Key: X25519, 253 bits
---
Server Temp Key: X25519, 253 bits
---
Server Temp Key: X25519, 253 bits
---

What to read out of this.

• The same group every time — X25519 — but a different key pair each time. "Temp" is the tell. The group is a negotiated parameter; the actual key is generated fresh per connection and discarded after.
• Master-Key is empty on TLS 1.3, and that is deliberate. On TLS 1.2 OpenSSL prints the master secret here. TLS 1.3 uses a key schedule deriving many separate keys, so there is no single master secret to print. If you need to decrypt your own traffic in Wireshark you use SSLKEYLOGFILE instead, not this field.
• X25519 is a Montgomery curve, not one of the NIST P-curves from Module 02. It was chosen for TLS because it is fast and its implementation avoids several classes of side-channel bug that plagued P-256. It is the default group in essentially every modern client.

💡 253 bits looks odd next to X25519's name. The curve uses 255-bit arithmetic and the usable scalar range works out to 253 bits. It is not a weakness and not a typo — it is just an honest count.

The property that compromising a server's long-term private key does not allow decryption of past sessions.

It comes from using ephemeral Diffie-Hellman (ECDHE) for key agreement: both sides generate throwaway key pairs per connection, derive a shared secret, and destroy the private halves. The certificate's key is used only to sign the handshake, proving identity — it never carries the session key.

Without it — old RSA key transport, where the client encrypted the pre-master secret to the server's public key — anyone who later obtains that private key can decrypt every recorded session, retroactively and completely.

Why it is not theoretical: "harvest now, decrypt later" is a real adversary model. Traffic recorded today can be decrypted whenever the key is obtained, whether by compromise, legal compulsion, or eventually a quantum computer. TLS 1.3 removed all non-forward-secret key exchange for exactly this reason.

The operational check: openssl s_client ... | grep 'Server Temp Key'. If that line is present you have forward secrecy; if it is absent on a TLS 1.2 connection, you do not.

TLS_AES_256_GCM_SHA384         TLSv1.3 Kx=any  Au=any  Enc=AESGCM(256)            Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256   TLSv1.3 Kx=any  Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256         TLSv1.3 Kx=any  Au=any  Enc=AESGCM(128)            Mac=AEAD

--- versus TLS 1.2 ---
45
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2 Kx=ECDH  Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH  Au=RSA   Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256  TLSv1.2 Kx=ECDH  Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256    TLSv1.2 Kx=ECDH  Au=RSA   Enc=AESGCM(128) Mac=AEAD

What to read out of this — the Kx and Au columns are the entire story.

• Three TLS 1.3 suites, forty-five TLS 1.2 suites on the same build — and that is already a hardened default list. Historically over 300 were defined.
• Kx=any Au=any on every 1.3 suite. Key exchange and authentication were removed from the cipher suite in TLS 1.3 and negotiated separately. A 1.3 suite names only the bulk cipher and the hash.
• Kx=ECDH Au=ECDSA on the 1.2 suites. In 1.2 the suite bundles four decisions into one name, which is why ECDHE-ECDSA-AES256-GCM-SHA384 is such a mouthful — and why the same cipher appears four times with different key exchange and authentication combinations.
• Mac=AEAD on all of them. Every suite listed is authenticated encryption — encryption and integrity in one operation. TLS 1.3 permits nothing else, which eliminates the entire family of padding-oracle attacks (BEAST, Lucky13, POODLE) that plagued the older CBC suites.
• Only three of the five 1.3 suites appear. The two CCM ones are compiled out or disabled by default here — normal for a general-purpose build; they matter only for constrained devices.

🔑 The practical consequence for your job: TLS 1.3 configuration is nearly a non-decision. You cannot pick a bad suite because none is offered. Cipher configuration only matters for the TLS 1.2 you still have to support — and there the right move is not to hand-craft a list but to copy a maintained one from TLSRef (which is where Mozilla's Server Side TLS guidance moved to), matching the compatibility level you actually need.

Four separate decisions in one name:

• ECDHE — key exchange: Elliptic Curve Diffie-Hellman, Ephemeral. The final E is the important letter: it means forward secrecy.
• RSA — authentication: the server's certificate holds an RSA key, used to sign the handshake.
• AES128-GCM — bulk encryption: AES with a 128-bit key in Galois/Counter Mode, which is AEAD, so it authenticates as well as encrypts.
• SHA256 — the hash used for key derivation (and for the MAC in non-AEAD suites).

The contrast worth drawing: the TLS 1.3 equivalent is just TLS_AES_128_GCM_SHA256. Key exchange and authentication were removed from the suite name and negotiated independently, which is why 1.3 has five suites where 1.2 had hundreds.

And the practical read: if a suite name does not start with ECDHE or DHE, it has no forward secrecy. Plain AES128-GCM-SHA256 means RSA key transport, and should not be enabled in 2026.

I would not hand-craft one. I would take a maintained configuration from TLSRef — the successor to Mozilla's Server Side TLS guidance — and pick the compatibility profile the business actually needs: Modern (TLS 1.3 only) if every client is current, Intermediate otherwise.

The reasoning: hand-written cipher strings age badly. A list that was excellent in 2018 permits things that are now considered weak, and nobody revisits it. Pointing at a maintained source means the decision gets re-made by people who track it.

The specifics I would still check myself: TLS 1.0 and 1.1 disabled, no non-forward-secret suites, no CBC suites if TLS 1.2 clients allow it, and server cipher preference disabled for TLS 1.3 (it does not apply) but considered for 1.2.

And the honest framing: for TLS 1.3 this is nearly a non-decision — all five suites are safe. Cipher configuration is really about the TLS 1.2 you still have to support, and the best long-term fix is to reduce the population that needs it.

>>> TLS 1.2, Handshake [length 00d1], ClientHello
<<< TLS 1.2, Handshake [length 0041], ServerHello
<<< TLS 1.2, Handshake [length 097d], Certificate
<<< TLS 1.2, Handshake [length 0074], ServerKeyExchange
<<< TLS 1.2, Handshake [length 0004], ServerHelloDone
>>> TLS 1.2, Handshake [length 0025], ClientKeyExchange
>>> TLS 1.2, ChangeCipherSpec [length 0001]
>>> TLS 1.2, Handshake [length 0010], Finished
<<< TLS 1.2, Handshake [length 00ba], NewSessionTicket
<<< TLS 1.2, ChangeCipherSpec [length 0001]
<<< TLS 1.2, Handshake [length 0010], Finished

What to read out of this — compare it line by line with Exercise B1.1.

• Count the direction changes. >>> … <<< … >>> … <<<. That is two round trips. TLS 1.3 had one. On a connection with 100 ms latency, that is 100 ms saved on every new connection, before any data moves.
• No InnerContent markers, and no encryption until ChangeCipherSpec. Everything above that line is in the clear — including Certificate. A passive observer on a TLS 1.2 connection can see exactly which certificate the server presented; on 1.3 they cannot.
• ServerKeyExchange is the message TLS 1.3 deleted. In 1.2 the server has to send its ephemeral DH share as a separate signed message, because it did not know the cipher suite when the ClientHello arrived. In 1.3 the share rides along inside ServerHello.
• ServerHelloDone [length 0004] — four bytes whose entire purpose is to say "I have finished talking". TLS 1.3 removed it; the structure makes it unnecessary.
• Certificate [length 097d] = 2,429 bytes, versus 2,434 in the 1.3 run. Essentially identical — the same certificate. The difference is not size, it is that 1.3 encrypts it.
• ChangeCipherSpec is real here. In TLS 1.3 (Exercise B1.1) the same message appears but is a compatibility fossil. Here it genuinely signals the switch to encryption.

🔑 The summary worth being able to give: "TLS 1.3 is one round trip instead of two, encrypts the certificate, and deletes ServerKeyExchange and ServerHelloDone. It gets there by having the client guess the key exchange group in advance."

40A7D24DF97F0000:error:0A0000BF:SSL routines:tls_setup_handshake:no protocols available:../ssl/statem/statem_lib.c:104:
CONNECTED(00000003)
---
exit code: 1

What to read out of this.

• no protocols available came from your own client, not from the server. Look at the ordering: the error appears before CONNECTED. OpenSSL refused to even construct a ClientHello — no packet was sent.
• That is a distribution-level policy, not a protocol one. Debian and Ubuntu ship OpenSSL with a minimum security level that excludes TLS 1.0 and 1.1 entirely. RHEL does the same through crypto-policies. The code still exists; it is switched off.
• This matters when you are asked to test a legacy device. You will hit this wall before you reach the device, and the fix is a client-side override such as -cipher 'DEFAULT@SECLEVEL=0' -tls1_1, not a change on the server. Knowing that the wall is on your side saves a confusing hour.

💡 TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in March 2021, and browsers removed them in 2020. If a system genuinely requires them, that is a finding to raise rather than a configuration to accommodate.

=== what does a normal TLS 1.2 connection negotiate? ===
Server Temp Key: X25519, 253 bits
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384

=== now demand a non-forward-secret RSA suite ===
40E7A1B2C87F0000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

What to read out of this.

• The normal connection has Server Temp Key — forward secrecy, from ECDHE. And note the cipher name starts with ECDHE, which is the quick visual check.
• AES256-SHA has no ECDHE or DHE prefix. That is RSA key transport: no forward secrecy, and CBC mode rather than AEAD.
• The handshake failed because our certificate holds an EC key, and RSA key transport requires an RSA key. So this server structurally cannot do it — an accidental but real benefit of choosing EC (Module 02, A1).
• sslv3 alert handshake failure is the generic "we could not agree" alert. It says nothing about why, which is why cipher mismatches are frustrating to debug: you must compare both sides' lists yourself.

🔑 The three-second forward-secrecy check on any server:

openssl s_client -connect host:443 -servername host </dev/null 2>/dev/null | grep 'Server Temp Key'

Line present → forward secrecy. Line absent on TLS 1.2 → RSA key transport, and a finding worth raising. On TLS 1.3 the line is always present, because there is no alternative.

Five that matter, roughly in order of impact:

1. One round trip instead of two. The client guesses the key exchange group and sends its key share in the ClientHello. A wrong guess costs a HelloRetryRequest, which is rare.
2. Forward secrecy is mandatory. RSA key transport and static Diffie-Hellman were removed entirely, so every session gets ephemeral key agreement.
3. The menu was cut from hundreds of cipher suites to five, all AEAD. CBC modes, RC4, 3DES, export ciphers, MD5 and SHA-1 signatures, and compression are all gone — which eliminates BEAST, Lucky13, POODLE, CRIME and the rest as a category.
4. More of the handshake is encrypted, including the server's Certificate message. A passive observer can no longer see which certificate was presented.
5. Cipher suites no longer encode key exchange or authentication — those are negotiated separately, which is why TLS_AES_128_GCM_SHA256 is so much shorter than ECDHE-RSA-AES128-GCM-SHA256.

The detail that shows you have looked at a real handshake: 1.3 still sends ChangeCipherSpec, which it does not need, purely so middleboxes written for 1.2 do not drop the connection. RFC 8446 calls it compatibility mode.

And the operational note: 1.3 also added 0-RTT resumption, which is genuinely faster and carries a replay risk — so it should only be enabled for idempotent requests.

Two reasons, and the first is the important one.

No forward secrecy. With RSA key transport the client encrypts the pre-master secret to the server's public key, so anyone who later obtains that private key can decrypt every recorded session retroactively. That makes "harvest now, decrypt later" a viable strategy — record traffic today, obtain the key by compromise or compulsion at leisure.

A twenty-five-year history of padding oracles. RSA key transport in TLS used PKCS#1 v1.5, the source of repeated Bleichenbacher attacks from 1998 through ROBOT in 2017. Each round was patched; each round something new appeared. TLS 1.3 concluded that a construction which keeps producing the same class of vulnerability should be deleted rather than defended.

The visible consequence: a TLS 1.3 server certificate needs only digitalSignature in Key Usage. keyEncipherment existed to let the certificate key decrypt the pre-master secret, and has no purpose once key transport is gone.

=== WITH -servername ===
subject=C = MY, O = Zaeem Labs, CN = app.internal.test

=== WITHOUT it ===
subject=C = MY, O = Zaeem Labs, CN = app.internal.test

=== is the hostname visible on the wire? ===
extension_type=server_name(0), length=22
    0000 - 00 14 00 00 11 61 70 70-2e 69 6e 74 65 72 6e 61   .....app.interna
    0010 - 6c 2e 74 65 73 74                                 l.test

What to read out of this.

• Both returned the same certificate here, because our lab server hosts only one. That is the honest result and it is worth noticing: on a single-site server, SNI changes nothing.
• On a multi-site server it changes everything. Omit -servername and you get whichever certificate the default virtual host serves — usually the first one defined, and usually the wrong one. This is the single most common cause of "the wrong certificate is being served".
• Look at the hex dump. 61 70 70 2e 69 6e 74 65 72 6e 61 6c 2e 74 65 73 74 is app.internal.test in ASCII, in plaintext, in the first packet. Nothing is encrypted yet. That is SNI's privacy cost, in bytes you can read.

🔑 The diagnostic this gives you. When someone reports the wrong certificate being served, compare with and without -servername:

openssl s_client -connect host:443 -servername host </dev/null 2>/dev/null | openssl x509 -noout -subject
openssl s_client -connect host:443                  </dev/null 2>/dev/null | openssl x509 -noout -subject

If they differ, it is a virtual-host or SNI configuration problem, not a certificate problem — and the fix is in the web server config, not at the CA. If a client is failing, check whether it sends SNI at all; some very old and embedded clients do not.

=== ask for HTTP/2, fall back to HTTP/1.1 ===
No ALPN negotiated

=== ask for something nobody supports ===
No ALPN negotiated

What to read out of this — and "No ALPN negotiated" is the correct result here.

• openssl s_server does not speak HTTP/2, so it has nothing to agree to and declines to pick. That is ALPN working properly: no common protocol, no selection, and the connection continues on whatever the application assumes.
• Against a real HTTP/2 site you would see ALPN protocol: h2. Try it: openssl s_client -connect www.google.com:443 -servername www.google.com -alpn h2,http/1.1 </dev/null 2>/dev/null | grep -i alpn
• The protocol names are exact strings from an IANA registry: h2 for HTTP/2, http/1.1, h3 for HTTP/3 over QUIC, acme-tls/1 for the TLS-ALPN-01 certificate challenge you will meet in Module 10.

💡 Where ALPN bites in operations: a load balancer that advertises h2 to clients but speaks only HTTP/1.1 to the backend, or a proxy that strips the extension. The symptom is protocol errors that look like application bugs. -alpn on s_client tells you what each hop actually agreed to.

New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Reused, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384

What to read out of this.

• One New, five Reused. Only the first connection did a full handshake. The other five skipped the certificate entirely.
• The saving is large. A resumed handshake sends no Certificate message — that is the 2,400-byte message from Exercise B1.1 gone, plus the signature verification and the chain validation. On a page pulling fifty resources, this is most of the TLS cost.
• The cipher stayed the same. Resumption reuses the negotiated parameters; it does not renegotiate them.

⚠️ Now try the same thing on TLS 1.3 and it will report New every time. That is not a bug and it is worth understanding, because it will confuse you otherwise.

In TLS 1.2 the server offers a session ID or ticket during the handshake. In TLS 1.3 the ticket arrives in a NewSessionTicket message after the handshake completes — so a client that connects and immediately disconnects (which is what </dev/null does) never receives one. -reconnect was designed for the TLS 1.2 model and does not demonstrate 1.3 resumption reliably.

🔑 The operational version of that same fact: in TLS 1.3, resumption state is established after the first connection is useful. A client making exactly one short-lived connection never benefits. This is why resumption helps browsers enormously and helps one-shot health-check scripts not at all.

A way to skip the expensive part of a handshake on subsequent connections. The server issues a ticket (or, in TLS 1.2, a session ID) after a full handshake; the client presents it next time, and both sides resume from the previously established secret.

The saving is substantial: no Certificate message — typically 2–4 KB — no signature verification, and no chain validation. On a page loading many resources over separate connections, this is most of the TLS cost.

The version difference worth knowing: TLS 1.2 establishes the session during the handshake, so -reconnect demonstrates it easily. TLS 1.3 sends the ticket in a NewSessionTicket message after the handshake completes, so a client that connects and immediately closes never gets one. That surprises people testing resumption on 1.3.

The operational caveat: tickets are encrypted with a session ticket key held by the server. If that key is long-lived and never rotated, it becomes a forward-secrecy hole — anyone obtaining it can decrypt every resumed session. Ticket keys should rotate frequently, and must be shared correctly across a load-balanced fleet or resumption silently stops working.

TLS 1.3 lets a resuming client send application data in its first packet, before the handshake completes — zero round trips of latency.

The problem is replay. Early data is sent before any live exchange with the server, so there is no shared state to bind it to this connection. An attacker who records that first packet can send it again later and the server has no reliable way to distinguish it. RFC 8446 Appendix E.5 documents this and deliberately does not forbid 0-RTT; it pushes the responsibility to the application.

The practical rule: only idempotent requests. GET for static content is fine; anything that changes state is not. In nginx, $ssl_early_data tells you a request arrived as early data, and the standard pattern is to return 425 Too Early for anything non-idempotent.

What this signals in an interview: being willing to say "this feature is a performance win with a correctness hazard, and here is where I would and would not enable it" is worth more than either enthusiasm or blanket refusal.

On OpenSSL 3.0.x (what most distributions still ship in 2026):

OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)

=== does this build know ML-KEM? ===
(no -kem-algorithms subcommand - this build predates OpenSSL 3.5)

=== which groups can this client offer? ===
 -groups val                 Specify supported groups (ECDHE groups)

=== ask a real server for a PQ group ===
40C7B1E2A87F0000:error:0A00018E:SSL routines:...:no suitable signature algorithm

On OpenSSL 3.5+:

Server Temp Key: X25519MLKEM768, 256 bits

What to read out of this.

• Your distribution's OpenSSL is probably too old, and that is the honest state of things in 2026. Ubuntu 24.04 ships 3.0.x; RHEL 9 ships 3.0.x or 3.2. Post-quantum support in browsers ran well ahead of post-quantum support in server distributions, which is exactly why origin-side adoption sits around 10% while client-side is at two thirds.
• Server Temp Key: X25519MLKEM768, 256 bits is what success looks like — the same field you have been reading since Exercise A1.1, now naming a hybrid group.
• You do not need to do anything to your certificates. This is a key exchange change, not a signature change. Your existing RSA or EC certificate works unmodified. Post-quantum signatures (ML-DSA) are a separate and much slower migration, because they require new certificates, new CA hierarchies, and root programme approval.

🔑 The distinction to be crisp about in an interview: "Post-quantum key exchange is deployed now and needs no certificate changes — it protects against harvest-now-decrypt-later. Post-quantum signatures are a much bigger migration and are not urgent, because a signature only needs to resist forgery during the certificate's lifetime, which is now measured in months."

It is here already for key exchange. The deployed mechanism is X25519MLKEM768, a hybrid combining classical X25519 with ML-KEM-768 (NIST FIPS 203). Both run, and the session key derives from both, so it holds if either does.

It is on by default in Chrome and Edge since version 131 (November 2024), and by 2026 Cloudflare reports roughly two thirds of human-generated TLS traffic using it — up from under 3% in early 2024. Notably it is still an IETF draft, which is unusual at that scale.

Yes, it matters now, because of harvest now, decrypt later: an adversary recording traffic today can decrypt it whenever the capability arrives. Anything with a decade-long secrecy requirement is already exposed.

The distinction that shows real understanding: this is a key exchange change and needs no certificate changes at all — your existing RSA or EC certificate is unaffected. Post-quantum signatures (ML-DSA) are a separate, much larger migration requiring new certificates and CA hierarchies, and they are less urgent, because a signature only needs to resist forgery during the certificate's lifetime — which is heading toward 47 days.

The practical gap to name: browsers moved faster than server distributions. OpenSSL gained ML-KEM in 3.5, but most distributions still ship 3.0.x, which is why origin-side support is around 10% while client support is at two thirds.

#!/usr/bin/env bash
# tlsinfo - inspect what a TLS endpoint actually negotiates
set -uo pipefail
host="${1:?usage: tlsinfo <hostname> [port]}"; port="${2:-443}"
S="openssl s_client -connect ${host}:${port} -servername ${host}"

printf '\n  %s:%s\n  %s\n\n' "$host" "$port" "$(printf '=%.0s' {1..58})"

# --- 1 & 2. what was negotiated ---
out=$($S </dev/null 2>/dev/null)
proto=$(printf '%s' "$out" | grep -m1 'Protocol *:' | sed 's/.*: *//')
ciph=$( printf '%s' "$out" | grep -m1 'Cipher *:'   | sed 's/.*: *//')
tmpk=$( printf '%s' "$out" | grep -m1 'Server Temp Key' | sed 's/.*: *//')
sigt=$( printf '%s' "$out" | grep -m1 'Peer signature type' | sed 's/.*: *//')

printf '  %-16s %s\n' "Protocol"  "${proto:-unknown}"
printf '  %-16s %s\n' "Cipher"    "${ciph:-unknown}"
printf '  %-16s %s\n' "Key group" "${tmpk:-<none>}"
printf '  %-16s %s\n' "Cert sig"  "${sigt:-unknown}"

if [ -n "$tmpk" ]; then
  printf '  %-16s ✅ yes (ephemeral %s)\n' "Forward secrecy" "${tmpk%%,*}"
else
  printf '  %-16s ❌ NO - RSA key transport. Recorded traffic is decryptable\n' "Forward secrecy"
fi

# --- 3. which versions are accepted ---
printf '\n  Protocol support:\n'
for v in tls1 tls1_1 tls1_2 tls1_3; do
  label=$(printf '%s' "$v" | sed 's/tls1_/TLS 1./; s/^tls1$/TLS 1.0/')
  if $S -$v </dev/null >/dev/null 2>&1; then
    case "$v" in
      tls1|tls1_1) printf '    %-10s ⚠️  ACCEPTED - deprecated by RFC 8996\n' "$label" ;;
      *)           printf '    %-10s ✅ accepted\n' "$label" ;;
    esac
  else
    printf '    %-10s ·  not offered\n' "$label"
  fi
done

# --- 4. SNI behaviour ---
with=$($S </dev/null 2>/dev/null | openssl x509 -noout -subject 2>/dev/null)
without=$(openssl s_client -connect "${host}:${port}" </dev/null 2>/dev/null \
          | openssl x509 -noout -subject 2>/dev/null)
printf '\n  SNI:\n'
printf '    with SNI     %s\n' "${with:-<none>}"
printf '    without SNI  %s\n' "${without:-<none>}"
[ "$with" != "$without" ] && printf '    ℹ️  differ - name-based virtual hosting is in use\n'

# --- 5. ALPN ---
alpn=$($S -alpn h2,http/1.1 </dev/null 2>/dev/null | grep -m1 -i 'ALPN protocol' | sed 's/.*: *//')
printf '\n  %-16s %s\n' "ALPN" "${alpn:-none negotiated}"

# --- 6. chain length ---
n=$($S -showcerts </dev/null 2>/dev/null | grep -c 'BEGIN CERTIFICATE')
printf '  %-16s %s certificate(s)\n' "Chain sent" "$n"
[ "$n" -eq 1 ] && printf '    ⚠️  only ONE - intermediates missing. Browsers may hide this; curl/Java will fail\n'
printf '\n'

Try it:

chmod +x tlsinfo
./tlsinfo www.google.com
./tlsinfo app.internal.test 4433     # your own lab server

The five design decisions worth understanding.

1. One connection for the summary, separate connections for probing. Requirement 3 needs a distinct handshake per version — you cannot learn which versions a server accepts from a single connection, because only one gets negotiated.

2. Forward secrecy is inferred from Server Temp Key, not from the cipher name. The cipher name works for TLS 1.2 (ECDHE- prefix) but not for 1.3, where key exchange was removed from the suite name. Server Temp Key is the field that works for both.

3. TLS 1.0/1.1 being accepted is flagged as a warning, not a fact. Reporting a value is less useful than reporting a judgement. A tool that says "⚠️ deprecated by RFC 8996" tells the reader what to do; one that prints "TLS 1.0: yes" does not.

4. The SNI comparison is a diagnostic, not a pass/fail. Differing certificates are perfectly normal on a shared host — it just tells you name-based virtual hosting is in play, which is the context you need when someone reports the wrong certificate.

5. The chain warning names who will fail. "Browsers may hide this; curl and Java will fail" is the sentence that prevents the argument, exactly as in Module 03's capstone.

What to add as you go through the track: revocation status and OCSP stapling (Module 09), HSTS and redirect behaviour (Module 08), and full cipher enumeration (Module 13). By Module 13 this and Module 03's certinfo merge into one genuinely useful auditing tool.

-tls1                      Just use TLSv1
-tls1_1                    Just use TLSv1.1
-tls1_2                    Just use TLSv1.2
-tls1_3                    Just use TLSv1.3
-no_tls1                   Disable TLSv1
-no_tls1_1                 Disable TLSv1.1
-no_tls1_2                 Disable TLSv1.2
-no_tls1_3                 Disable TLSv1.3
-dtls                      Use any version of DTLS

What to read out of this.

• Two families: -tls1_2 forces exactly that version; -no_tls1_2 excludes it. For probing what a server supports you want the forcing form, one version per connection — which is what the capstone does.
• The -no_ forms are for testing fallback. -no_tls1_3 tells you what a client that cannot do 1.3 would get, which is how you check whether your TLS 1.2 configuration is still sane.
• -dtls is Datagram TLS, TLS over UDP — used by WebRTC, some VPNs and QUIC's ancestors. Same certificates, same chains, different transport. Out of scope here but worth recognising.

💡 A caveat you already met in Exercise C1.2: forcing -tls1 or -tls1_1 may fail in your own client before a packet is sent, because your distribution's security level forbids them. That is a client-side refusal, and the workaround is -cipher 'DEFAULT@SECLEVEL=0'. Without knowing that, you can wrongly conclude a server has already disabled them.

Negotiate parameters, authenticate the server, agree a shared symmetric key — in that order. Agreeing a key before checking identity would establish a private channel with an unknown party, which is exactly the man-in-the-middle case.

Not in TLS 1.3, and almost never in modern 1.2. It is used only to sign the handshake transcript, proving possession. The session key comes from a separate ephemeral Diffie-Hellman exchange the certificate takes no part in.

That separation is what gives forward secrecy.

The client guesses the key exchange group and sends its key share in the ClientHello, before knowing what the server will choose. A correct guess — which is nearly always — completes the exchange in one trip. A wrong guess costs a HelloRetryRequest and one extra trip.

Compromising the server's long-term private key does not decrypt past sessions, because the session key came from ephemeral keys that were destroyed.

Check with openssl s_client ... | grep 'Server Temp Key'. Present means yes. Absent on a TLS 1.2 connection means RSA key transport and no forward secrecy.

Ephemeral elliptic-curve Diffie-Hellman for key exchange (the trailing E is what gives forward secrecy); RSA certificate for authentication; AES-128 in GCM — an AEAD mode — for bulk encryption; SHA-256 for key derivation.

The TLS 1.3 equivalent is just TLS_AES_128_GCM_SHA256, because key exchange and authentication were removed from the suite name.

No forward secrecy — the pre-master secret is encrypted to the certificate's public key, so obtaining that key later decrypts everything recorded. And a twenty-five-year run of Bleichenbacher padding-oracle attacks against PKCS#1 v1.5, most recently ROBOT in 2017.

The consequence you can see: a TLS 1.3 server certificate needs only digitalSignature, not keyEncipherment.

Deleted: ServerKeyExchange (the share moved into ServerHello) and ServerHelloDone (the structure makes it unnecessary).

Kept as a fossil: ChangeCipherSpec. TLS 1.3 does not need it — key changes are implied — but it is still sent so middleboxes written for 1.2 do not drop the connection. RFC 8446 calls this compatibility mode.

Server Name Indication: the hostname the client is asking for, sent in the ClientHello so a server hosting many sites knows which certificate to present.

Not encrypted, even in TLS 1.3 — it is in the very first message, before any keys exist. So a passive observer still learns which site you visited. Encrypted Client Hello (ECH) is the fix.

Diagnostic value: if the certificate differs with and without -servername, you have a virtual-host configuration issue rather than a certificate issue.

Sending application data in the first packet of a resumed TLS 1.3 connection — zero round trips.

It cannot be protected against replay: there is no shared state yet, so a recorded first packet can be sent again. Enable it only for idempotent requests — static GETs at a CDN — and have the application reject non-idempotent early data, e.g. 425 Too Early using nginx's $ssl_early_data.

In 1.2 the session is established during the handshake. In 1.3 the ticket arrives in a NewSessionTicket message after the handshake completes, so a client that connects and immediately closes never receives one.

Practically: resumption helps browsers making many connections, and does nothing for one-shot scripts. It also means openssl s_client -reconnect demonstrates 1.2 resumption cleanly but not 1.3.

A hybrid key exchange combining classical X25519 with post-quantum ML-KEM-768 (NIST FIPS 203). The session key derives from both, so it holds if either does.

Now, because of harvest now, decrypt later — traffic recorded today can be decrypted whenever the capability arrives, so anything with long-term secrecy is already at risk. Default in Chrome and Edge since v131; roughly two thirds of human browser traffic by 2026; still an IETF draft.

It needs no certificate changes — it is key exchange, not signatures. Post-quantum signatures are a separate and far larger migration.

Not disable TLS 1.3. The protocol already ships a compatibility fossil — the redundant ChangeCipherSpec — specifically so 1.2-era middleboxes tolerate it. A device that still breaks is failing at its job and needs updating or replacing.

Disabling 1.3 to accommodate it costs forward-secrecy guarantees, the round-trip saving, and certificate privacy, permanently, to work around one broken appliance.

Question selection was cross-referenced against publicly published 2026 TLS and SSL interview question sets, then rewritten and deepened:

• ClimbTheLadder — 10 SSL Handshake Interview Questions and Answers
• InterviewPrep — Top 25 SSL Interview Questions and Answers
• JavaInUse — Top OpenSSL Interview Questions (2026)
• Devinterview.io — Web Security interview questions for 2026

Every handshake trace and negotiated-parameter output in this module was captured on OpenSSL 3.0.13 against a locally run s_server, including the side-by-side TLS 1.3 and TLS 1.2 message flows, the three-suite TLS 1.3 menu, the TLS 1.2 resumption run, and the no protocols available client-side refusal of TLS 1.1. The observation that openssl s_client -reconnect does not demonstrate TLS 1.3 resumption — because the ticket arrives after the handshake — came from testing rather than recall.

Standards and current adoption were verified against primary sources: RFC 8446, RFC 5246, RFC 6066, RFC 7301, draft-ietf-tls-ecdhe-mlkem, NIST FIPS 203, OpenSSL's post-quantum documentation, and Cloudflare adoption figures reported through 2026.

Answers were rewritten and deepened rather than reproduced — published versions are usually correct but shallow, and the added operational detail is what actually differentiates a candidate in the room.