AP Cybersecurity · Unit 5 · Topic 5.4 · Exercise 2
TLS Handshake Breakdown
Walk through a TLS 1.3 handshake stage by stage. Six questions tracing what happens at each step: Client Hello, Server Hello + Certificate, Certificate Verify, Forward Secrecy analysis, Application Data phase, and a synthesis.
6 Questions~18 minApplied · Scored
How This Exercise Works
Each question covers one stage of a real TLS 1.3 handshake.
Connecting principle: Asymmetric crypto for identity + key exchange; symmetric crypto for bulk data; hashing for integrity and key derivation. If you lose track of which primitive is doing what, re-read section 5.4.8 of the main lesson.
Score0 / 6
Question 1
Stage 1 — Client Hello. A client initiates a TLS 1.3 handshake with a bank's server. In the Client Hello message, the client includes an ephemeral ECDH public key share, supported cipher suites, and a random nonce. Why does the client send an EPHEMERAL public key (not its long-term identity key)?
✎ Predict before reading options. Commit to your answer first.
Exam TipClient ephemeral key = no long-term client identity + forward secrecy via fresh DH. Server still authenticates via certificate.
Question 2
Stage 2 — Server Hello and Certificate. The server responds with its own ephemeral ECDH share, a chosen cipher suite, and its certificate chain. The client's browser now has: the ephemeral public keys from both sides, and a certificate claiming to bind the server's long-term public key to bank.com. What does the client do next to establish trust?
✎ Predict before reading options. Commit to your answer first.
Exam TipCertificate validation = chain + hostname + expiration + revocation. ALL must pass. ALL.
Question 3
Stage 3 — Certificate Verify. After the client validates the certificate, the server signs the entire handshake transcript with its LONG-TERM private key (matching the public key in the certificate). Why is this step necessary? Couldn't the client just trust the certificate?
✎ Predict before reading options. Commit to your answer first.
Exam TipCertificate Verify = proof of private-key possession. Certificates alone are just public documents; signing proves ownership of the matching private key.
Question 4
Stage 4 — Forward Secrecy Analysis. Suppose an attacker records a TLS 1.3 session today. Five years from now, they somehow obtain the server's long-term private key (matching the certificate used today). Can they decrypt the recorded session?
✎ Predict before reading options. Commit to your answer first.
Exam TipTLS 1.3 = mandatory forward secrecy via ephemeral ECDH. Long-term key is for authentication only, not session key derivation.
Question 5
Stage 5 — Application Data Phase. Once the handshake completes, all subsequent application data (HTTP requests, responses, cookies) flows encrypted. Which cryptographic primitive is doing this bulk encryption, and why not use the asymmetric keys that were just negotiated?
✎ Predict before reading options. Commit to your answer first.
Exam TipHandshake = asymmetric (slow, one-time). Application data = symmetric AEAD (fast, continuous). Never use asymmetric for bulk data.
Question 6
Synthesis question. Given the complete TLS 1.3 handshake flow, which of the following controls would provide the MOST comprehensive protection for a highly sensitive web application? Select the best option.
✎ Predict before reading options. Commit to your answer first.
Exam TipLayered defense: TLS 1.3 + ECC + CT + hostname checks + rotation + pinning. Each control blocks a different class of attack.
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed.
Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Typically responds within 24 hours
✓
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.