MY robot has finished a measurement at a demonstration venue. It needs to send its lab report to lab.example and receive instructions for the next test. Secure Boot has checked its startup code, but the report still has to cross someone else’s network. If a stranger pretends to be the lab, what evidence should the robot require before handing over its data?
This is a fictional teaching scenario. The main path is a TLS 1.3 full handshake with certificate-based server authentication and ephemeral ECDHE key agreement. Resumption, 0-RTT and mutual certificate authentication appear as separate branches later. The current TLS 1.3 specification is RFC 9846, published in July 2026, which replaces RFC 8446. The protocol version is still TLS 1.3.[1]
1. What does the attacker want from this connection?
Before the robot sends anything, MY circles two assets: an unpublished lab report and test commands that can change the device’s behavior. An attacker might copy the report, alter a measurement or inject a command that appears to come from the lab. A message can reach its destination while the task still fails.
For this example, the attacker controls the network path and can observe, forward, insert, replay or drop traffic. Initially, the attacker has neither endpoint’s secrets and cannot change the robot’s trust anchors. These are explicit threat-model assumptions; sharing a Wi-Fi network does not automatically give every user all these capabilities. TLS aims to provide confidentiality, integrity and the applicable peer authentication across a hostile path. The attacker can still interrupt service, so availability needs other defenses.[1, §1 and Appendix F.1]
The word “secure” hides several different questions. If an outsider reads the unpublished measurements, confidentiality has failed. If the outsider cannot read them but causes the receiver to accept altered data, integrity has failed. These failures can occur separately. Making bytes unreadable does not, by itself, explain how the receiver will detect a change.
Authentication concerns the source of the exchange. A test command with the correct format only shows that someone knows the format; it does not identify its sender. The robot needs evidence linking received content to the peer authenticated in this connection. Permission is a further decision: even an authenticated sender may have no right to delete calibration files. A parser that understands a command has not yet established either of these things. Otherwise, learning the command syntax would effectively grant control of the device.
There is also an attack that requires no cryptanalysis: discard the traffic. The report can remain secret and every implemented check can be correct, while the lab receives nothing. TLS cannot force a controlled network path to forward data. The product still needs a timeout policy, a decision about retaining the report, and a safe state for the device while communication is unavailable. Those are availability and operational decisions in this example, not properties obtained by choosing a longer encryption key.[1, §1 and Appendix F.1]
If the attacker could already read the robot’s memory, it might obtain the report before encryption. We initially exclude that capability so we can examine what TLS contributes against an attacker on the path. Endpoint protection, application behavior and key storage will re-enter the story later. Secure Boot has checked startup code, but it does not name a trustworthy recipient for every network connection. The robot could still learn to encrypt and then hand its report to a stranger.
2. How can an encrypted report still leak?
The robot proposes a shortcut: find someone who can encrypt, then lock the report. MY draws two connections. The robot talks to a fake lab, which opens a second connection to the real lab. Both links can be encrypted, but the fake lab is a decryption endpoint on each. It sees the report in plaintext.
This counterexample deliberately removes the check that the peer is the intended service. Key agreement and encryption alone cannot identify that peer. Correctly validated TLS binds the peer identity, handshake and keys together so an attacker on the path cannot freely substitute an endpoint. The robot needs an independently established destination, lab.example; it cannot adopt whatever name the stranger presents as its test for success.[1, §2 and Appendix F.1; 2, §6.1]
Call the two connections’ secrets K1 and K2. These are teaching labels, not TLS key names. The robot and fake lab use K1; the fake lab and real lab use K2. When the robot’s ciphertext reaches the intermediary, it decrypts with K1, reads the report and encrypts with K2 for delivery to the real lab. Replies can take the reverse route. The intermediary need not break either connection’s encryption: it is already a participant holding the relevant key on each one.
Asking whether plaintext travels on the wire therefore misses the failure. Both links in this deliberately unauthenticated example can carry ciphertext, while an attacker controls the endpoint between them. Selecting a sound encryption algorithm does not correct the choice of recipient. This differs from an observer recording unchanged ciphertext beside a cable.
A node that merely relays the robot’s exchange with the real lab does not become a key-agreement participant just because packets pass through it. If it leaves the peers’ key shares intact and obtains none of their secrets, it does not acquire the decrypt-and-reencrypt position represented by K1 and K2. Routers must transport packets; TLS is designed to allow untrusted transport. The problem is accepting a transporter as the intended communication peer.[1, §2 and Appendix F.1]
The identity evidence must therefore connect to the materials used for this actual connection. Receiving a separate document about lab.example, without checking its relationship to the current handshake, could let an attacker combine its own key exchange with someone else’s public credentials. This is why the protocol needs more than two unrelated checkboxes labeled “encryption enabled” and “certificate seen.”
3. How do strangers establish a shared secret?
The robot sends a ClientHello with acceptable versions, algorithm-related options and ephemeral public key material in key_share. The lab selects parameters and returns its own public material in ServerHello. In the ECDHE path used here, each side keeps its ephemeral private value and combines it with the peer’s public contribution to compute the same shared secret. Neither the shared secret nor the final traffic key needs to travel across the network in its raw form.[1, §§2, 4.2, 4.3.8 and 7.4]
Ephemeral material is created for this exchange using secure randomness and erased when no longer needed. Computing a secret lets the exchange continue; it does not yet establish that the peer is the lab. Certificates and signatures supply that evidence later. This also connects to the RSA lesson: TLS 1.3 does not use RSA key transport on this path, although RSA can still participate in authentication through an appropriate signature scheme.[1, §§1.3, 4.5.2 and 7.4]
The ECC lesson’s point multiplication gives us a way to follow the shared-secret calculation. This is a symbolic ECDH explanation, not a complete TLS implementation. Let G be a common base point. The robot chooses an ephemeral private value a and computes the public point A = aG. The lab chooses b and computes B = bG. They can exchange A and B publicly while keeping a and b at their respective endpoints.
After receiving B, the robot computes aB; after receiving A, the lab computes bA. Since aB = a(bG) and bA = b(aG), both reach abG. The robot never needs to learn b, and the lab never needs to learn a. Actual TLS converts the required result into shared-secret bytes according to the negotiated group. For the specified short Weierstrass curves, that uses the shared point’s x coordinate. X25519 has its own defined inputs, outputs and checks; the symbolic point argument is not interchangeable implementation code for every group.[1, §7.4.2]
An observer has G, A and B, so why not do the same calculation? It lacks a or b. With suitable groups and correct implementations, recovering the required secret from the public information is assumed computationally infeasible. Predictable private values could let an attacker guess an input and bypass that hard problem. A public algorithm can coexist with secret inputs produced by secure randomness; hiding the algorithm is not the source of confidentiality.
Notice that lab.example appears nowhere in the algebra. A fake lab can choose a private value and send a public share too. Successful calculation establishes a secret with a participant; it does not establish that participant’s service identity. The subsequent checks must connect the exchange to the intended service. Erasing ephemeral material addresses a different question—what a later compromise reveals—which we will revisit under forward secrecy.
Engineer extension: three algorithm choices
A TLS 1.3 cipher suite selects the AEAD algorithm and HKDF hash, as in TLS_AES_128_GCM_SHA256. The key-exchange group and signature algorithm are negotiated separately. An AES suite name therefore does not tell you whether the certificate uses RSA or ECDSA. ECDHE illustrates the shared-secret step here; this lesson does not enumerate every PSK, hybrid or extension path. HelloRetryRequest is a branch for situations such as an unsuitable key share, not a mandatory message in every handshake.[1, §§4.2.1, 4.2.4, 4.3.3 and 4.3.7–4.3.8]
4. Why derive more keys from the shared secret?
The robot wants to use its new secret for everything. MY draws branches instead: one kind of protection for handshake messages, another for reports and commands, with separate directions for sending and receiving. TLS uses HKDF, specified labels and transcript hashes to derive stage-specific traffic secrets, then the working keys and IVs.[1, §§7.1 and 7.3; 3, §2]
After ServerHello, both sides can derive handshake traffic keys. EncryptedExtensions, Certificate, CertificateVerify and Finished can therefore be encrypted while peer authentication is still in progress. That timing matters: seeing ciphertext does not establish authentication success. HKDF also cannot manufacture entropy. Guessable input secrets or compromise of an upstream secret can still undermine the derived branches.[1, §§2, 4.5 and 7.1; 3, §3]
A traffic secret is material from which the protocol derives further protection material for particular traffic. It need not be the same bit string as the working key passed to AEAD. The TLS key schedule distinguishes handshake from application traffic, and client-sent from server-sent traffic, then derives the appropriate key and IV. Reading every box labeled “secret” or “key” as another name for one universal key loses those distinctions.[1, §§7.1 and 7.3]
HKDF-Extract prepares input secret material for subsequent use; HKDF-Expand incorporates information about the intended use into derivation. Labels distinguish the jobs assigned to outputs, but they participate in cryptographic computation rather than merely attaching a note to an unchanged key. Peers with the same secret and the same prescribed inputs can calculate corresponding outputs independently. They need not send each working key across the network.[3, §§2–3]
Separation has limits. Different labels help prevent material intended for one purpose from being confused with another, but they do not make a stolen upstream secret safe again. An attacker who obtains a source secret and the necessary public inputs can follow the relevant derivations too. Producing several keys and keeping their source secret are distinct requirements. Repeatedly hashing an easily guessed input does not automatically supply missing entropy.
Another input is the transcript hash: a digest of the handshake record as defined by the protocol. The negotiated information in the Hello messages is not discarded once the menu choices are made. Specified portions of that record participate in later derivation and verification. Differences in the required handshake content can make later checks fail. A hash alone requires no secret, however, so exchanging a digest is not identity proof. Its role in authentication comes from how a signature or a secret-key operation incorporates it.[1, §§4.1 and 7.1]
The robot can now decrypt subsequent handshake messages while still lacking sufficient evidence to trust their sender. There is no contradiction: decryption material is available before authentication checks are complete. In this example, the robot holds back its report while checking the name, signature, Finished and other necessary conditions.
Engineer extension: stages and directions
Our path has no PSK, but the key schedule still uses the specified zero input for the absent PSK. It proceeds through Early Secret, a Handshake Secret that incorporates ECDHE, and Main Secret. Handshake traffic secrets use the transcript through ServerHello; the first application traffic secrets use it through server Finished. Handshake/application and client/server roles have distinct derivation labels. The current term is Main Secret, but literal labels containing master remain for compatibility and must not be rewritten. Extract and Expand are cryptographic operations, not simply slicing a bit string into pieces.[1, §7.1]
5. Does this certificate identify the intended service?
The fake lab presents a certificate genuinely signed by a trusted CA, but its name is other.example. A valid signature is not enough. The robot validates a certificate path to a locally trusted anchor, checks validity and applicable policy, and compares its expected service name with the certificate’s identity. For DNS names, it checks dNSName entries in subjectAltName; a familiar-looking Common Name is not a substitute.[2, §§1.2 and 6; 6, §§4 and 6]
The expected name must come from trusted configuration or the destination originally chosen by the user, independently of the certificate being tested. In this example, the robot stops the confidential upload and records the reason when name or path validation fails. That is the application’s chosen policy. An incorrect clock, missing intermediate certificate or policy mismatch can also cause failure. A failure does not prove an attack, and disabling validation is not a routine repair.[2, §§6.1 and 6.6; 4]
A certificate can be understood as a verifiable introduction to a public key, provided we keep the limits of that analogy in view. It contains a name, public key, validity period and other fields, with an issuer’s signature over the defined certificate content. The robot must do more than recognize the issuer’s printed name. It checks signatures along an applicable certification path back to a locally accepted trust anchor, together with the path’s purpose and constraints. A collection of certificates ending in a self-signed one is not automatically an acceptable path.[6, §§4 and 6]
“Locally accepted” supplies an independent starting point. The fake lab could create a CA key, issue itself a certificate for lab.example, and include its own root certificate in the package. The signatures might be mathematically consistent, but the robot has no reason to accept that new root. Letting the sender supply both the evidence and the rule for trusting it would remove the independent check. A chain extends an existing trust decision; it cannot create trust in an unknown issuer merely by being internally consistent.
Name matching asks whether that introduction concerns the service the robot intended to reach. The expected destination comes from trusted configuration naming lab.example. A perfectly valid certificate for other.example does not satisfy that destination. If the robot instead changes its expected name to whatever the presented certificate says, every impostor can pass the comparison. The reference name must be established independently of the evidence being judged.[2, §6.1]
Troubleshooting should preserve these distinctions. An incorrect device date may cause the wrong judgment about a certificate’s validity period. A missing intermediate can prevent path construction. A name mismatch may indicate the wrong destination or a deployment configuration error. Diagnose the failing check and repair its cause. Disabling validation may restore communication, but successful delivery then says nothing about whether the intended recipient received the report.
The robot can now accept that this public key has an appropriate, policy-validated relationship to the intended service. The certificate is still public information. Anyone can download a copy without knowing a private key, so the introduction has not yet shown that this connection involves the corresponding signing capability.
6. A certificate can be copied. Where is the live proof?
The attacker now copies the public certificate for lab.example, complete with the correct name. The robot still needs CertificateVerify. The lab signs a context-bound transcript hash with the corresponding private key, and the robot checks it with the public key in the validated certificate. This connects the service identity to the current handshake and protects the handshake covered by the signature. Copying a certificate does not confer that signing ability.[1, §4.5.2]
The drawing’s identity card and live demonstration are analogies. The protocol does not sign an arbitrary sentence saying “I am the lab,” and it does not use a public-key signature for every application packet. A protected signing service may hold the private key, so successful proof does not establish that the key sits in the web server’s RAM. If an attacker simply forwards the real peers’ handshake and ciphertext unchanged, it remains a relay; forwarding alone gives it no traffic key with which to decrypt the report.[1, §§2 and 4.5.2]
Think of the transcript as a handshake record maintained independently by each peer. It is not a narrative supplied by the other side and accepted without checking. The receiver calculates the required digest from the handshake messages actually exchanged, using the protocol’s encoding and rules. Both content and order matter. If the robot’s original Hello differs from the version received by the lab, the records used for verification can differ too.[1, §4.1]
Why not sign a permanently reusable statement saying “I am the lab”? Such a statement does not connect the current Hello messages, key shares and exchange. Someone who obtains its signature could keep presenting it. CertificateVerify includes the required handshake digest in a role-contextualized signature input, tying the evidence to the current handshake instead of a reusable introduction. For the server signature in this example, the transcript ends at server Certificate. It excludes the CertificateVerify being produced and the Finished messages that follow.[1, §4.5.2]
The receiver’s work is concrete. It obtains the public key from the policy-validated certificate, reconstructs the required transcript hash from the messages it has observed, and checks the received signature using an allowed signature algorithm. The public key, covered message and signature must agree. Pasting a signature from a different handshake onto this one, or inserting another key share into previously signed content, does not preserve that verification result.
The hash represents the required handshake record; the signature supplies evidence of the corresponding private-key capability. Someone who can calculate a hash need not possess the private key. Someone who downloads a certificate need not be able to sign either. The fake lab’s certificate copy supplies public introduction material, but not the ability to produce the corresponding signature for the current exchange. Under our assumptions of uncompromised keys and unchanged trust settings, copying the file does not fill that gap.
After connecting the service identity to this exchange, the peers still need to verify the handshake-derived material and relevant record. Finished uses a key derived from handshake secrets, rather than another signature made with the certificate’s private key.
Engineer extension: the actual signature input
CertificateVerify signs a concatenation of 64 0x20 octets, a role-specific context string, a single 0x00 separator and the Transcript-Hash through Certificate. Server and client context strings differ. These fields help separate this signature from signatures in other contexts; the input cannot be replaced with an unqualified public key or random challenge. The transcript uses the specified handshake-message encoding, excluding record headers.[1, §§4.1 and 4.5.2]
7. What does Finished confirm?
CertificateVerify supplies signature evidence, but each side must still complete its Finished message. Finished uses a key derived from the corresponding handshake traffic secret to calculate HMAC over the transcript hash of the applicable prefix. The receiver checks the result for key confirmation and handshake integrity. Modified messages can fail signature or record checks before reaching Finished; failure need not wait for one final checkpoint.[1, §§4.5 and 4.5.3]
In our example, the robot validates server Finished and sends client Finished; the lab validates client Finished before the report and command exchange begins. The two Finished messages cover different prefixes. Each includes the prior applicable handshake messages and excludes itself. Client Finished includes the earlier server Finished, so the two sides are not stamping identical copies of a completed conversation.[1, §4.5]
HMAC is a message-authentication computation using a secret key. Anyone with the same public handshake record can recompute its ordinary hash. Incorporating a finished key derived from the relevant handshake traffic secret makes verification depend on prescribed secret material as well. The receiver uses the corresponding key and its own transcript hash to recompute the expected value and compare it with Finished. Key confirmation does not mean exposing the keys for comparison.[1, §4.5.3]
Follow server Finished once. The lab derives a finished key for its sending direction and computes an HMAC over the transcript hash of the prefix required at that point. The robot can derive corresponding material and check it. A mismatch in the secret or required record prevents successful verification. This complements CertificateVerify, but must be considered alongside the necessary identity and signature checks. Passing Finished alone is no reason to skip name validation.
The robot then sends client Finished. It has already received server Finished, so the required transcript prefix extends further. Each peer uses the range defined for that point, rather than signing off on an identical complete conversation twice. Excluding the Finished currently being calculated also avoids a circular definition: including its own value as input would require knowing the computation’s result before performing it.
Our main example requests no client certificate. Accepting client Finished therefore does not tell the lab which registered robot has connected. It confirms the corresponding handshake evidence; device identity still requires an additional authentication design. Section nine will connect that distinction to mTLS. First, we can follow the report into the record layer and see what happens to altered data.
MY robot lab.example
ClientHello + key_share ---------------------->
<---- ServerHello + key_share
Both sides derive directional handshake keys
<---- {EncryptedExtensions}
<---- {Certificate}
<---- {CertificateVerify}
<---- {server Finished}
{client Finished} ---------------------------->
[Lab report] -------------------------------->
<---- [Test command]
{}: handshake traffic keys; []: application traffic keysThis path has no PSK, client certificate or HelloRetryRequest. TLS permits a server to send application data after sending its own Finished and before receiving client Finished. At that point, it has not thereby established the client’s identity or liveness. Our diagram uses a simpler waiting policy.[1, §§2 and 4.5.3]
8. What happens when the attacker changes a measurement?
The report starts moving. The attacker changes ciphertext in the hope that the lab will read a different measurement. TLS 1.3 protects records with AEAD, combining encryption and authentication, for example through AES-GCM or ChaCha20-Poly1305. The receiver must successfully authenticate a record before treating its decrypted output as valid. A failed record check terminates the connection; the application must not continue with an unverified partial result.[1, §5.2]
Reports and returning commands use different directional traffic secrets, keys and IVs. Each direction also maintains a sequence number used to form the record nonce, avoiding nonce reuse under a given key. The protected unit is a TLS record, not necessarily one IP packet or one complete application transaction. Network segmentation, retransmission and application framing operate at different layers.[1, §§5.1–5.3]
Ciphertext that looks nothing like the report is not automatically proof that alterations will be detected. Encryption and authentication have different jobs; TLS 1.3 uses AEAD to provide both. The sender supplies plaintext, a key, a nonce and the additional data that must be authenticated. The operation produces ciphertext and an authentication tag. The receiver checks the tag with the corresponding inputs before accepting the decrypted result. The tag need not be secret. Its purpose is to make an acceptable tag for altered content difficult to forge without the key.[1, §5.2]
Compare this with an ordinary unkeyed hash attached to a report. If an attacker can replace both, it can compute a fresh hash for its replacement report. A matching pair still does not tell the receiver who supplied it. AEAD authentication incorporates a secret key, so knowing the public algorithm does not give an on-path attacker the same freedom to create an acceptable tag for modified content. The design depends on the key and the cryptographic construction, not on hiding the checking procedure.
The nonce matters because one key protects many records. It normally does not need secrecy, but it must satisfy the algorithm’s requirements under that key and cannot simply be reused at will. TLS forms each record nonce from that direction’s sequence number and IV, allowing the receiver to reconstruct it. The peers therefore need both the appropriate directional key and consistent record state. Copying ciphertext from a different connection does not turn it into an ordinary valid record on the new one.[1, §5.3]
Even a valid record says less than “the experiment is complete.” A report may span several records. Every received record can be authentic while the final portion never arrives because the network fails. The lab still needs application framing, length or completion checks, and a defined processing result. A valid earlier tag cannot stand in for the missing remainder. Nor does TLS judge whether a measurement is physically plausible: a legitimate endpoint can send an incorrect value, and TLS can transport that value faithfully.[1, §6.1]
Engineer extension: integrity is not exactly-once execution
TLS 1.3 left-pads the 64-bit record sequence number to the IV length and XORs it with the direction’s write IV to form the nonce. Sequence numbers cannot wrap and reset when traffic keys change. AEAD additional data includes the record header. An application retry can send the same command over another valid connection, so transaction identity and deduplication remain separate concerns. A sudden disconnect also does not prove the entire report arrived merely because the last received record had a valid tag. Application framing, length checks and handling of TLS close_notify still matter.[1, §§5.2–5.3 and 6.1]
The experiment computes ECDH, HKDF and AES-GCM, but uses classroom record headers and derivation labels. Compare tag failures after changing direction, sequence or ciphertext. These operations check specified inputs; they do not run a TLS handshake, its standard key schedule or certificate validation. They cannot establish the security of an actual connection.
9. Does the lab know which robot is connected?
The robot has authenticated the lab, but that does not automatically answer the reverse question. An ordinary server-certificate handshake does not authenticate a device certificate for every client. Client Finished confirms handshake keys and transcript state; it is not, by itself, proof of a particular robot’s identity. A service can use application login, or choose mTLS and request a client certificate with the corresponding private-key proof.[1, §§4.4.2 and 4.5]
Even when both identities are authenticated, commands need authorization. Our fictional policy permits report uploads and specific tests but denies ordinary operators permission to delete calibration files. The robot must not execute “delete calibration” merely because the TLS indicator is green. Certificate or login identities must be mapped to roles, resources and allowed actions. This is an application-design inference: TLS authentication supplies an input to authorization, not the product’s rules for every command.[1, §1 and Appendix F.1]
Client and server name roles in a connection, not trustworthy and untrustworthy parties. The robot initiates this connection and is the client; the lab accepts it and is the server. Earlier certificate checks let the robot identify the lab, but did not require every initiating client to present a device certificate. Client Finished shows that the client can complete the corresponding handshake-key confirmation. The lab cannot infer a registered robot’s serial number from that message alone.[1, §4.5]
If the product chooses mTLS, the lab requests a client certificate in the applicable flow, and the robot supplies the corresponding private-key proof. The lab then validates the credential and determines how the authenticated identity maps to its device registry. The identity fields and policy for client authentication depend on the product. The preceding section’s rules for matching a server DNS name should not be transplanted indiscriminately onto every device certificate.[1, §§4.4.2 and 4.5]
Suppose this application maps a robot’s authenticated identity to a role that permits report uploads and operations on that robot alone. A request to modify another device’s calibration file should still fail even when authentication succeeds. Authorization must consider the requester, the resource and the action together. Leaving out the resource can produce a system in which a genuine user can operate on someone else’s data. This is an illustrative application policy, not a role system prescribed by TLS for every service.
Now suppose someone steals a legitimate robot’s private key and can use it to authenticate. The cryptographic evidence may still verify: the check establishes a relationship to the credential and signing capability, not the physical identity of the human operating the stolen material. Device-key protection, revocation, suspicious-operation detection and limited permissions therefore retain separate jobs. Reducing all these judgments to one green indicator makes it easy to forget which checks have not occurred.
10. If the signing key leaks tomorrow, can today's capture be decrypted?
Today the attacker records ciphertext. Tomorrow it steals the lab’s long-term signing key. For the completed ECDHE handshake in our story, compromise of that key alone does not reconstruct the earlier traffic keys, provided ephemeral and session material has been securely erased and the cryptographic and implementation assumptions hold. This is forward secrecy with respect to long-term keys.[1, Appendix F.1]
Change the condition and the answer can change. Compromise of a running host may expose plaintext, traffic secrets in RAM or retained key logs. An attacker with an acceptable certificate and corresponding signing capability may also impersonate the lab in new connections. Forward secrecy addresses a particular later compromise of long-term keys; it does not promise secrecy after arbitrary endpoint compromise or protect session material that was never erased.[1, Appendix F.1]
Keep two kinds of private material in separate mental drawers. The lab’s long-term signing key supports its authenticated identity across many connections. The ephemeral ECDHE private value contributes to this connection’s shared-secret calculation; the key schedule then derives traffic material. Separating those roles makes it possible to protect a completed session even after the long-term signing key leaks.[1, §§4.5.2, 7.1 and 7.4]
Follow the sequence in time. Today, the attacker records Hello messages, public key shares and ciphertext, but obtains no private values. After the session, both peers securely erase ephemeral and session material they no longer need. Tomorrow, the attacker gets the lab’s signing key. It now has a signing capability, but that key was not the input used to calculate yesterday’s ECDHE shared secret. Substituting it into the recorded public exchange does not recover that secret. Creating a new signature also cannot change which private values the peers actually used yesterday.
That is why a forward-secrecy claim must identify the compromised asset. A retained TLS key log may already contain the session material needed for decryption, bypassing any need to attack ECDHE. A running endpoint may hold the plaintext in application memory. Both cases change what the attacker obtains; neither can be evaluated by repeating the conclusion for signing-key theft alone.[1, Appendix F.1]
Protecting earlier sessions also does not justify continued use of a stolen identity key. An attacker with an acceptable certificate and its corresponding signing capability may authenticate an impersonating endpoint in a new connection. KeyUpdate on an existing connection is not a universal repair either. If its current traffic secret has leaked, the attacker can follow the derivation of later traffic secrets for that same sending direction on the connection. The product must address the compromise, authentication material and establishment of a safe new connection; a key-update operation alone does not necessarily remove the attacker.[1, §7.2 and Appendices F.1.5 and F.2]
11. Can a reconnect send commands before the handshake finishes?
The demonstration network drops and returns. The robot wants to avoid repeating all the earlier work. A prior connection can establish a PSK for resumption. If the subsequent PSK handshake is accepted, it carries forward that security context without resending the server’s Certificate and CertificateVerify. Resumption does not require 0-RTT. Resuming with fresh ECDHE and using a PSK alone also have different forward-secrecy properties. For a PSK-only resumed session, later compromise of that PSK, together with the recorded handshake, lets an attacker derive the session’s traffic material. A secure fresh ECDHE exchange with erased ephemeral material prevents that PSK alone from recovering the post-handshake traffic keys. Early data is a separate case because it was sent before that new exchange completed.[1, §2.2]
With 0-RTT, the client can send early data before receiving the new ServerHello. That reduces waiting, but there is no general cross-connection guarantee against replay, and the protocol does not guarantee forward secrecy for that early data. Replaying “run another test” could cause another physical action. Our example policy therefore waits for the handshake before sending operations with side effects and separately uses transaction identifiers and deduplication. A GET method or a claim of idempotence alone is not sufficient evidence that replay is safe.[1, §§2.3 and 8]
Resumption draws on a security context established earlier. A server can supply a ticket following a connection, while the client retains the associated resumption material. On reconnecting, the client proposes a PSK identity and provides the corresponding handshake evidence. Servers may use different designs to store or reconstruct the state associated with a ticket. Returning a copied ticket string alone should not be confused with authentication: the protocol also needs the correct PSK evidence and subsequent verification.[1, §§2.2, 4.3.11 and 4.7.1]
Avoiding another full certificate exchange and sending side-effecting data early are separate choices. The robot can resume a connection but wait for the new handshake before sending a test command. If it chooses 0-RTT, it must encrypt early data before receiving the server’s new contribution. It cannot claim that these already-sent bytes were protected using an ECDHE secret that becomes available only later in the exchange.[1, §§2.2–2.3 and 7.1]
Replay does not require understanding the command. Imagine an attacker retaining an acceptable early-data transmission and causing it to appear in another connection context where it can be accepted. Without sufficient deployment-level restrictions, the lab may receive the same request again. TLS 1.3 does not provide a general cross-connection non-replay guarantee. Servers can mitigate replay with additional state and other measures, but applications need to understand the assumptions. This is distinct from duplicating a record within the same connection.[1, §§2.3 and 8]
Waiting for the handshake still leaves another kind of repetition. The lab may execute a test, then lose the reply during a network failure. The robot knows only that it received no result. It cannot distinguish “never executed” from “executed but reply lost,” so it may submit another legitimate request. A fresh TLS connection can carry it securely without recognizing that it describes the same job. Execution control needs application transaction identifiers, deduplication state and result-query behavior. The identifier also needs a relationship to the identity, request content and retention policy; attaching a number is not an exactly-once guarantee.
For this robot’s physical actions, our example waits for the handshake and then applies the application’s transaction policy. After an interrupted exchange, it checks the preceding operation’s result. That costs waiting time but suits the example better than guessing how many times the measurement equipment moved. Whether another request is suitable for 0-RTT depends on the consequences of repetition, not merely its HTTP method name.
12. Where does the protection stop?
Back at the demonstration table, the robot has a trusted configuration naming lab.example. Certificate path and name checks meet policy, the peer proves its signing capability for this handshake, and Finished and record checks pass. The application also checks the sender’s identity, complete report receipt and command permissions. Together, these conditions support the decision to deliver the report and execute the permitted test. Secure Boot checks the startup path; TLS authenticates the network peer and protects traffic. Each addresses a part of the system’s trust problem.
Moving the lab service behind a proxy introduces another security boundary. Suppose the robot’s TLS connection ends at the proxy, which decrypts the report and forwards it to a backend. That terminator is the other end of this cryptographic connection. This can be an intentional, controlled deployment rather than an attack. Nevertheless, the proxy can access plaintext, so its access controls, logging policy and compromise risks belong in the threat model. If the backend leg also uses TLS, it is a separate connection with its own peer validation and keys.[1, §9.3]
Confidentiality does not mean that observers cannot tell communication is happening. Packets need routable addresses; their lengths and timing may also reveal clues. In the base case without ECH, ClientHello SNI may expose a service name. Proper ECH deployment reduces that particular exposure, but protects specified fields rather than every source of information. DNS queries, destination IP addresses or traffic characteristics may still provide clues. Encrypting one field cannot establish destination anonymity by itself, and the difference matters when describing what the product protects.[1, Appendix F.3; 5, §§1 and 10.7]
Now change one condition: a faulty robot has a valid mTLS credential but reports an incorrect measurement. TLS can authenticate the transport identity and protect the data on the path without proving that the measurement is correct. The backend might need range checks, comparisons with other sensors or device-state evidence. These are possible application designs, selected according to the measurement’s purpose and available evidence, not automatic TLS features. The next lesson, Key Management / Key Hierarchy, follows the long-term signing, device and session keys from creation through storage, rotation and revocation.
Five points to keep
- Start with the attacker’s capabilities; encryption needs validation of the intended peer.
- ECDHE establishes a shared secret; HKDF derives material for different stages and directions.
- Certificate path/name checks, CertificateVerify and Finished provide complementary evidence.
- AEAD protects records; device identity, command permission and transaction deduplication still need suitable mechanisms.
- Forward secrecy, 0-RTT, TLS termination and endpoint compromise each have distinct conditions.
Glossary
| Term | Its job in this story |
|---|---|
| TLS | Establishes a transport channel with applicable authentication and data protection. |
| ECDHE | Agrees a shared secret using ephemeral elliptic-curve key material. |
| HKDF | Extracts and derives purpose-specific material; it does not manufacture entropy. |
| Transcript | The handshake-message history accumulated under the protocol’s rules. |
| CertificateVerify | Binds the corresponding private-key capability to the current handshake using a signature. |
| Finished | Confirms the handshake and keys through a derived-key MAC. |
| AEAD | Combines encryption and authentication for record protection. |
| mTLS | Uses certificates to authenticate both TLS peers; authorization remains separate. |
| Forward secrecy | Under its assumptions, later long-term-key compromise does not reveal past session keys. |
| 0-RTT | Early data sent before handshake completion, with different replay and secrecy guarantees. |
References
1. IETF, RFC 9846: TLS 1.3, 2026.
2. IETF, RFC 9525: Service Identity in TLS, 2023.
3. IETF, RFC 5869: HKDF, 2010.
4. IETF, RFC 9325: TLS/DTLS Recommendations, 2022.
5. IETF, RFC 9849: TLS Encrypted Client Hello, 2026.
6. IETF, RFC 5280: X.509 Certificates and CRLs, 2008.
#TLS #SecureChannel #HardwareSecurity #ECDHE #HKDF #PKI #ComicClassroom
Change bytes, direction or sequence: does the record pass?
Compare both ECDH shared secrets, directional keys and the record nonce. Change only ciphertext, direction or receiver sequence. Then keep a valid tag but remove certificate acceptance or permission, separating record authentication from service access.
Web Crypto performs ECDH P-256, HKDF-SHA-256 and AES-GCM; nonces illustrate IV XOR padded sequence. This custom record experiment has no TLS wire format, standard key schedule, certificate parser, handshake transcript or Finished validation. It is not a TLS implementation or interoperability test. Certificate acceptance and permission are supplied conditions.
Learning guide
Security Foundations
Open the course outline → · Progress counts published lessons only
Prerequisites
- Digital Signature and Certificate & PKI are helpful background.
What I learned
- Explain the hostile-path threat and why encryption needs peer authentication.
- Connect ECDHE, HKDF, certificates, Finished and AEAD.
- Separate transport protection from authorization, replay safety and endpoint trust.