TLS 1.3 Handshake Replay Workout (NET-101 Week 10)

This is a Tier-1-graded worksheet. Submit this filled worksheet only. The Tier-2 capture-and-decode lab (Lab 10-1) is the deeper artifact; today is the annotated calibration that prepares you for it. After you finish this worksheet, Lab 10-1 will feel like recognition rather than discovery.

Purpose

Week 10 §2 introduced the six-packet TLS 1.3 handshake that follows every TCP connection to an HTTPS server. Week 10 §3 introduced the encryption boundary: the first two packets (ClientHello and ServerHello) are plaintext on the wire; everything from EncryptedExtensions onward is wrapped in content_type 0x17. Week 10 §4 introduced the certificate-chain trust model and the role of CertificateVerify in binding the certificate to this specific connection. Today's worksheet drives the TLS 1.3 handshake replay panel in pcap-tools over the academy-tls13.pcap fixture so you can see all three play out in sequence.

The replay panel mounts above the standard pcap-tools 3-pane view (packet table + protocol-tree + hex). It adds step controls, a client/server state-pill display that tracks both endpoints through the RFC 8446 Appendix A state machine, authored callout text per step, and a wire-view box showing the key field values encoded in each packet. Clicking Step forward advances the packet-table selection, so the protocol-tree and hex panes follow along. You use those affordances to answer two kinds of question this worksheet poses: predictive (what state does the client enter after ServerHello? what record type wraps the EncryptedExtensions?) and observational (the state pills now read WAIT_EE and NEGOTIATED; what packet just played, and what does the server have that the client has not yet received?).

The pedagogical claim of Week 10 §2 is that TLS 1.3 achieves 1-RTT by moving the ECDHE key_share exchange into the first two plaintext packets, so both sides can derive handshake-traffic keys before the server sends its encrypted flight. The replay makes that claim concrete: you can read the key_share extension in the ClientHello fields, see the server's key_share reply in the ServerHello, and then watch the EncryptedExtensions arrive immediately in the same network flight. The deeper purpose: this worksheet calibrates your mental model of the TLS state machine against the canonical packet sequence. Lab 10-1 will hand you a different capture and ask you to identify each step without the callouts; if today's calibration sticks, Lab 10-1 is a recognition exercise rather than a discovery exercise.

Learning Objectives

By the end of this worksheet, you will be able to:

1. Name both endpoints' TLS state after each of the six packets using RFC 8446 Appendix A state labels (WAIT_SH, WAIT_EE, WAIT_CERT_CR, WAIT_CV, WAIT_FINISHED, CONNECTED for the client; RECVD_CH, NEGOTIATED, WAIT_FINISHED, CONNECTED for the server) (Apply; Week 10 §2).
2. Identify the two plaintext packets and four encrypted packets in the academy-tls13.pcap fixture and explain why content_type 0x17 appears on all encrypted records regardless of which handshake message they carry (Analyze; Week 10 §3).
3. Verify the legacy_version vs supported_versions distinction in the ClientHello and ServerHello fields: the record layer reads 0x0303 but the real version is announced in the supported_versions extension as 0x0304 (Apply; Week 10 §2).
4. Trace the cipher suite and key_share negotiation: which suites the client offers, which one the server selects, and which ECDHE group is used for the key exchange (Apply; Week 10 §2).
5. Articulate one observation about TLS 1.3 that the static sequence diagram (Week 10 Figure 10.1) could not surface, in 3-5 sentences (Evaluate; replay-vs-static-diagram distinction).

Equipment Checklist

• Modern web browser (Chromium-family preferred)
• pcap-tools URL open: https://virtuscyberacademy.org/pcap-tools/
• NET-101 Week 10 prose re-read through Section 4
• Week 10 Figure 10.1 (TLS 1.3 sequence diagram) visible in a second browser tab for comparison
• Paper notebook for state-machine predictions (do NOT click Step before you predict)
• TCP Handshake Replay worksheet (worksheets/net-101/lab-tcp-handshake-replay.md) submitted PASS (the state-pill + Step affordance is the same; the TLS state machine is more steps but the same pattern)

Step-by-Step Procedure

This worksheet takes approximately 75 minutes. Plan one sitting.

Stage 1 - Load pcap-tools and pick the fixture

• Step 1. Open pcap-tools at the URL above. Confirm you see the curated-capture dropdown, the packet-table pane, the protocol-tree pane, and the hex pane.
• Step 2. From the curated dropdown, pick academy-tls13.pcap (manifest id net-101-academy-tls13). The packet table fills with six rows. The replay panel mounts above the standard 3-pane view because the manifest entry carries a replay_mode field.
• Step 3. Confirm the replay panel shows: step controls (Start / Previous / Next), a state pill display reading Client: START and Server: START, a callout text area, and a wire-view box. The packet table currently has no row selected.

Stage 2 - Predict the TLS state machine before stepping

Before you click any Step button, fill the prediction columns in Table A from the Week 10 prose alone. The replay will then either confirm or correct each prediction.

• Step 4. From Week 10 §2 (the TLS 1.3 handshake): predict the client state and server state after each of the six packets plays. Fill the "Predicted client state" and "Predicted server state" columns in Table A for all seven rows (initial + after each of 6 packets). Use the RFC 8446 Appendix A labels: client states are START / WAIT_SH / WAIT_EE / WAIT_CERT_CR / WAIT_CV / WAIT_FINISHED / CONNECTED; server states are START / RECVD_CH / NEGOTIATED / WAIT_FINISHED / CONNECTED.
• Step 5. From Week 10 §3 (the record-layer content_type): predict which packets are plaintext (content_type 0x16, handshake record) and which are encrypted (content_type 0x17, application_data record). Fill the "Plaintext?" column in Table A. (Hint: only two packets are plaintext; once the server has sent its key_share, both sides can derive keys.)
• Step 6. Stop before stepping. Photograph or scan your paper predictions if your grader requires evidence the predictions came first.

Stage 3 - Step through the ClientHello and ServerHello (packets 1-2)

• Step 7. Click Start replay (or Next from the initial state). The replay advances to step 1: the ClientHello. State pills flip to Client: WAIT_SH and Server: RECVD_CH. Fill the Observation row for packet 1 in Table A. Then, from the protocol-tree pane:
  • Find the legacy_version field. Fill Table B row 1 (the raw bytes shown: 0x0303 or 0x0304?).
  • Find the supported_versions extension. Fill Table B row 2 (the version the client offers as TLS 1.3).
  • Find the key_share extension. Note the ECDHE group names. Fill Table B row 3.
  • Count the cipher suites in the ClientHello. Fill Table B row 4 (how many, and list the first two by name).
• Step 8. Click Next. The replay advances to step 2: the ServerHello. State pills flip to Client: WAIT_EE and Server: NEGOTIATED. Fill the Observation row for packet 2 in Table A. Then, from the protocol-tree pane:
  • Find the cipher_suite selected by the server. Fill Table B row 5.
  • Find the server's key_share reply. Fill Table B row 6 (which group did the server choose?).
  • Note the content_type in the TLS record header. Fill Table B row 7 (still 0x16, or already 0x17?).

Stage 4 - Step through the encrypted server flight (packets 3-5)

• Step 9. Click Next. The replay advances to step 3: the EncryptedExtensions. State pill on client flips to WAIT_CERT_CR. Fill the Observation row for packet 3 in Table A. Note: the protocol-tree pane shows content_type 0x17 (application_data) even though the payload is a TLS Handshake message. This is the encryption-boundary moment Week 10 §3 describes. Confirm the hex pane shows 17 03 03 as the record header bytes (content_type=0x17, legacy_version=0x0303).
• Step 10. Click Next. The replay advances to step 4: the Certificate. State pill on client flips to WAIT_CV. Fill the Observation row for packet 4 in Table A. Then read the callout text. The callout will describe the cert chain. Fill Table C (subject, issuer, key algorithm, and one SAN entry) from the callout or from the protocol-tree pane if the cert fields are visible.
• Step 11. Click Next. The replay advances to step 5: the CertificateVerify and server Finished combined in one flight. Both state pills flip to WAIT_FINISHED. Fill the Observation row for packet 5 in Table A. Read the wire-view box. Fill Table D row 1 (which secret is derived at this step, per the callout).

Stage 5 - Step through the Client Finished and summary (packet 6)

• Step 12. Click Next. The replay advances to step 6: the client Finished. Both state pills flip to CONNECTED. Fill the Observation row for packet 6 in Table A. Fill Table D row 2 (both sides now hold the application traffic secret; what keys are now active per the callout?).
• Step 13. Click Next once more. The replay shows the summary screen ("Handshake Complete: 1 RTT"). Fill Table E from the summary values the screen lists.

Stage 6 - Review the version-negotiation field and verify the 1-RTT count

• Step 14. Click Previous to return to step 1 (ClientHello). In the protocol-tree pane, locate the legacy_version field in the TLS record header and the supported_versions extension in the ClientHello extension list. Confirm: legacy_version = 0x0303 (TLS 1.2); supported_versions[0] = 0x0304 (TLS 1.3). Fill the "Verified" checkbox in Table B row 1 and row 2.
• Step 15. Click Replay (or reset to initial state). Count the round trips: the ClientHello goes out in one direction, the server's entire flight (ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished) comes back in one direction, and the client Finished closes it. That is one round trip from the client's perspective. Confirm this matches Table E's RTT count.

Stage 7 - Reflection

Answer the 6 reflection prompts below in 2-4 sentences each.

Data Entry Tables

Table A - TLS State Machine per Step (Steps 4-5 PREDICT; Steps 7-12 OBSERVE)

Fill Predicted columns before stepping. Fill Observed columns from the state pills after each Step click.

Encryption-boundary observation. After which packet does the first encrypted record appear? _____ (name the packet). At that moment, what has both sides derived that makes encryption possible? (One sentence.)

Table B - Cipher Suite and Key_Share Negotiation (Steps 7-8; Steps 14-15)

Fill rows 1-4 from the ClientHello fields. Fill rows 5-7 from the ServerHello fields.

Negotiation check. The server's cipher suite selection in row 5 must be from the client's offered list in row 4. Is it? [ ] Yes [ ] No. The group in row 6 must match one of the groups in row 3. [ ] Yes [ ] No.

Table C - Certificate Chain Reproduction (Step 10)

Fill from the replay callout text or from the protocol-tree cert fields after stepping to packet 4.

Binding check (from callout). CertificateVerify in packet 5 signs the transcript hash of all handshake messages sent so far. In one sentence, explain what this binding prevents. (Hint: an attacker with an old valid certificate for this domain.)

Table D - Handshake-Secrets Derivation (Steps 11-12)

Forward secrecy note. The handshake_secret is derived from the ephemeral ECDHE key exchange in rows 2 and ServerHello, not from the server's long-term certificate key. In one sentence, explain why this protects past sessions if the server's certificate private key is later compromised.

Table E - 1-RTT vs TLS 1.2 2-RTT Summary (Step 13; Step 15)

Fill the TLS 1.3 column from the summary screen. Fill the TLS 1.2 column from the Week 10 §2 prose comparison.

1-RTT saving. In TLS 1.2, the client had to wait for the server's entire first flight before it could send the ClientKeyExchange. In TLS 1.3, the client sends the key_share in the ClientHello so the server can derive keys immediately. In one sentence, state what the student observes in the fixture that confirms the 1-RTT count.

Reflection Prompts

Answer in 2-4 sentences each.

1. Why does TLS 1.3 use EncryptedExtensions instead of inlining those extension responses inside the ServerHello? The Week 10 §3 prose explains that TLS 1.3 moved the extension responses out of the plaintext ServerHello into an encrypted record. An on-path observer who sees the ServerHello can read the server's cipher suite selection and key_share group. If ALPN negotiation (the protocol the server selected: h2, http/1.1) were in the ServerHello, an observer could fingerprint the application-layer protocol from a plaintext field. Keeping extension responses in EncryptedExtensions hides that fingerprint. What other information carried in ServerHello extensions would you want to hide if you could? (Hint: look at the extension list in the Week 10 §2 prose, and think about what an on-path observer learns from each field that is still in the plaintext ServerHello.)

2. Why does the ClientHello publish all supported key_share groups rather than picking one and sending only that group's public key? TLS 1.3 allows the client to send public keys for multiple groups in one shot (so-called "key_share" entries) rather than negotiating the group first and then exchanging keys. The cost is a larger ClientHello (multiple Diffie-Hellman public values). The benefit is that the server can pick any one of the offered groups and immediately compute the shared secret, avoiding an extra round trip to request a different group. If the client sent only one key_share and the server did not support that group, what would happen? (Hint: RFC 8446 defines a HelloRetryRequest message for this case. The Week 10 §2 prose names it. What does it cost in round trips, and why is it a fallback-of-last-resort rather than the normal path?)

3. What does the Finished HMAC defend against when an on-path attacker tampers with cipher suite selection? The Finished message in TLS 1.3 is an HMAC over the transcript hash of every handshake message exchanged so far. Suppose an attacker intercepts the ClientHello and rewrites the cipher_suites list -- removing the strongest option and leaving only a weaker suite the client offered. Both endpoints still negotiate TLS 1.3 (the attacker left supported_versions intact), but their transcripts diverge: the client's hash covers the original cipher_suites list while the server's covers the modified one. When the server sends its Finished MAC computed over the server-side transcript, the client checks it against its own transcript hash; the hashes do not match, the MAC fails, and the client rejects the handshake. In one to two sentences, explain why this protection only works if the client checks the MAC before sending any application data.

4. How does TLS 1.3 defend against a version-downgrade attack where an attacker strips supported_versions entirely to force TLS 1.2 negotiation? This attack differs from Reflection 3: if supported_versions is stripped, both endpoints run TLS 1.2, and TLS 1.3's Finished MAC never executes at all -- so the transcript-divergence defense from Reflection 3 cannot apply. RFC 8446 §4.1.3 defines a separate mechanism: if a TLS 1.3-capable server negotiates TLS 1.2 because the client appeared not to support TLS 1.3, the server embeds the sentinel bytes 44 4F 57 4E 47 52 44 01 in the last 8 bytes of the ServerHello random field. A TLS 1.3-capable client that sees this sentinel in a TLS 1.2 ServerHello knows a downgrade was forced and aborts. In one to two sentences, explain why this case needs a separate defense and why the Finished HMAC alone cannot catch it.

5. What changes for session resumption via PSK (pre-shared key)? TLS 1.3 supports a session-resumption path where a previous connection establishes a PSK (encoded in a NewSessionTicket message the server sends after the handshake completes) and the client uses it in the next connection's ClientHello to skip the certificate exchange. The resumed handshake is still 1 RTT. The PSK proves the client was the party who completed the prior session, which substitutes for the server certificate in the resumed handshake. What does PSK resumption not provide that the full handshake provides? (Hint: a PSK derived from a previous session does not involve a fresh ECDHE exchange by default; RFC 8446 allows a hybrid mode called psk_dhe that adds a fresh ECDHE on top of the PSK. What property does the fresh ECDHE restore?)

6. What did you observe in the replay that Week 10 Figure 10.1's static sequence diagram could not surface? The diagram shows arrows, labels, and a shaded encryption-boundary region, but it cannot show state changing in real time or connect wire-level bytes to state transitions you watch happen. Name one specific moment, state-machine transition, or field value you only understood by stepping through the replay and watching the state pills update. Your Table A encryption-boundary observation is one candidate -- the moment content_type 0x17 appears in the hex pane while the state pill says WAIT_CERT_CR and the diagram's shaded region begins. In 3-5 sentences, describe what you observed and explain what the static diagram leaves out that the replay made concrete.

Tutor Hint Surface

If you get stuck on a step, the academy tutor at /tutor/ knows the context of this replay. Ask the tutor:

• "Why does legacy_version say 0x0303 if this is TLS 1.3?" -- the tutor will explain the middlebox-compatibility hack from RFC 8446 §4.1.2 and where the real version lives.
• "What is content_type 0x17 doing on EncryptedExtensions?" -- the tutor will explain why TLS 1.3 wraps all encrypted records in application_data type so on-path observers cannot fingerprint handshake message types.
• "What is CertificateVerify signing, and why does it matter?" -- the tutor will walk you through the transcript-hash construction and the replay-attack scenario it defeats.
• "What is the difference between this replay and Lab 10-1?" -- the tutor will explain that Lab 10-1 uses a different capture and asks you to identify fields without the callouts; this worksheet is the annotated calibration.

The tutor is a calibration aid, not a substitute for stepping through the replay yourself.

Submission Checklist

• This worksheet, with Tables A through E filled
• All 6 Reflection Prompts answered
• Prediction columns in Table A filled BEFORE the Observation columns (or honest acknowledgement if not)
• Table A encryption-boundary observation written in one sentence
• Table B negotiation check completed (both Yes boxes)
• Table C binding-check sentence written
• Table D forward-secrecy note written
• Toolchain Diary entry for the TLS 1.3 replay panel added

Pass/Fail Self-Evidence (Tier 1 of the rubric)

Every gate must be checked.

• Gate 1. Prediction columns in Table A filled before observations (honest confirmation of predict-before-step discipline).
• Gate 2. Table A shows exactly two packets marked plaintext (rows for ClientHello and ServerHello), and four marked encrypted (EncryptedExtensions, Certificate, CertificateVerify+Finished, Client Finished).
• Gate 3. Table B row 1 legacy_version = 0x0303; Table B row 2 supported_versions = 0x0304; both Verified checkboxes ticked (from Step 14 protocol-tree confirmation).
• Gate 4. Table A final row (after pkt 6, Client Finished) shows both client and server states as CONNECTED, confirming the full handshake completed.
• Gate 5. Reflection 3 (cipher-suite tampering) explains why the MAC fails when transcripts diverge AND why the client must check before sending data; Reflection 4 names the separate RFC 8446 §4.1.3 sentinel mechanism for the version-downgrade case.

If any gate is unchecked, do not submit yet.

Common Pitfalls

The five most common first-attempt failures:

1. Stepped before predicting. Table A loses its calibration value once predictions are back-filled. If you stepped first, redo with pcap-tools' standard (non-replay) view of the same fixture and fill Table A from the raw packet-table fields without the callout prompts.
2. Predicted the client as CONNECTED after ServerHello (step 2). The client is not connected after receiving the ServerHello; it enters WAIT_EE (waiting for EncryptedExtensions). CONNECTED only comes after both sides exchange Finished messages. Students who conflate "server sent its key_share so keys exist" with "handshake is complete" make this error.
3. Confused legacy_version (0x0303) with the negotiated TLS version (0x0304). The TLS record-layer header carries 0x0303 (TLS 1.2) for middlebox compatibility. The actual TLS 1.3 negotiation happens in the supported_versions extension. If your Table B row 1 reads 0x0304, you read the wrong field.
4. Marked EncryptedExtensions as plaintext. EncryptedExtensions is packet 3, not packet 2. Packet 2 is the last plaintext packet (ServerHello). The encryption boundary moves immediately after the ServerHello. Students who expect "TLS handshake messages are plaintext" miss the fact that TLS 1.3 moved most of the handshake behind the encryption boundary.
5. Skipped the callout text for packets 4 and 5. Table C (cert chain) and Table D (secrets derivation) require information from the callouts. If you stepped through quickly without reading, return to those steps using the Previous button and re-read before filling Tables C and D.

Forward Pointer

Lab 10-1 (TLS Handshake: capture and decode) uses a different fixture (a live capture you generate yourself using curl + tcpdump or Wireshark). Lab 10-1 asks you to identify each handshake step without callouts; today's worksheet is the annotated preview that makes Lab 10-1 a recognition exercise.

Lab 10-2 (Wireshark CVE Mini-Module) covers four CVEs in the Wireshark TLS dissector. The dissector parses the same ClientHello extensions you read in Step 7 today. The vulnerability is in how the dissector trusts extension length fields; the fields you read carefully today are exactly the ones a malformed ClientHello would falsify.

NET-101 capstone (Network Snapshot report) asks you to write a one-page protocol analysis of a real capture you collect on your own machine. A TLS handshake from a browser to an HTTPS server is one common target; the step-through-with-state-machine pattern from today is the foundation of that report.

SEC-101 Lab 5-1 (X.509 chain manual walk) covers the certificate fields in Table C in much greater depth: the ASN.1 encoding of the subject, the signature algorithm OID, the chain-of-trust from leaf to root CA. Today's replay showed where the cert lands on the wire (packet 4, encrypted); SEC-101 Lab 5-1 shows what is inside it.

Beyond NET-101: the same TLS state-machine pattern transfers to:

• WIR-101 captures (TLS over 802.11 shows the same six packets with different link-layer framing)
• PEN-101 (you intercept TLS via mitmproxy; the tools you use there terminate and re-originate the handshake you stepped through today)
• RE-101 SB6141 firmware analysis (the cable modem's TR-069 management channel uses TLS; understanding the handshake tells you what the modem establishes before any management data flows)

LAB WORKSHEET COMPLETE - TLS 1.3 Handshake Replay Workout v1.1; Tier-1; net-101-lab-tls-13-handshake-replay; polish pass: SHOULD-FIX R3 (cipher-suite-tampering scenario replaces conflated version-downgrade) + R4 (DOWNGRD sentinel for version-downgrade case) + R6 (LO#5 replay-vs-static-diagram) + chapter/chapter_title frontmatter; 6 reflection prompts total; em-dashes 0; phrase-blacklist 0.