1. Agree on a security shape
ClientHello offers versions, cipher suites, supported groups, key shares, signature algorithms, and optional PSK identities. The server selects a compatible set.
TLS/DTLS Handshake Workbench
Trace TLS 1.3 and DTLS 1.3 handshakes, key establishment, authentication, IoT credentials, and datagram reliability
animation
security
protocols
tls
dtls
iot
Learner-ready TLS/DTLS handshake workbench with TLS 1.3 message flow, DTLS cookie and retransmission behavior, credential options, IoT MTU and loss controls, diagnosis cards, quick reference, guided practice, and primary RFC source links.
TLS 1.3
DTLS 1.3
IoT security
Handshake
TLS/DTLS Handshake Workbench
Follow the messages that turn an untrusted network path into an authenticated encrypted channel. The default path is modern TLS 1.3; DTLS adds datagram safety when IoT traffic runs over UDP.
Current pathTLS 1.3 full handshake
Round trips1 RTT before data
Protection startsAfter ServerHello
IoT pressureCertificate chain size
Beginner ramp
What the learner should see first
TLS is not only encryption. The handshake negotiates algorithms, creates fresh traffic secrets, authenticates identities, and verifies that both endpoints saw the same transcript.
2. Derive traffic secrets
TLS 1.3 uses ephemeral (EC)DHE and HKDF-based key scheduling. Handshake messages after ServerHello are encrypted.
3. Prove identity and transcript
The certificate path, CertificateVerify, and Finished messages prevent a man-in-the-middle from silently changing the negotiated channel.
Interactive workbench
TLS 1.3 certificate handshake
A common HTTPS or MQTT-over-TLS path: one full round trip to authenticate the server and start encrypted application data.
TCP ordered stream
X.509 certificate
TLS 1.3
ClientHello: offer versions, cipher suites, groups, and key shares
The client starts in plaintext because no traffic secrets exist yet. It sends enough options for the server to choose one secure path.
Guided task flow
Read the current step like an engineer
Each card answers one inspection question. Click a card to jump to that step, then compare the visual, state cards, and diagnosis.
Diagnosis and feedback
What the current setup implies
The workbench keeps message flow, cryptographic purpose, and IoT deployment pressure synchronized so learners can reason beyond memorizing message names.
Security result
Negotiating a fresh authenticated channelThe endpoint has not finished transcript verification yet, so application data must wait.
Resource pressure
Certificate chain dominates bytesConstrained devices often use PSK, raw public keys, session resumption, or compact certificate handling to reduce handshake cost.
Transport behavior
TCP provides ordered delivery below TLSTLS can assume an ordered byte stream. DTLS must tolerate loss, reordering, replay, and datagram boundaries.
Evidence table
What each message proves
The table separates negotiation, key establishment, authentication, transcript verification, and datagram reliability.
| Evidence | Where to look | Common mistake |
|---|---|---|
| Compatible protocol version, cipher suite, group, and key share selected. | ClientHello and ServerHello. | Treating a cipher suite as the whole security policy. TLS 1.3 also negotiates groups, signatures, extensions, and PSK mode. |
| Fresh handshake and application traffic secrets can be derived. | Ephemeral (EC)DHE key shares or PSK key schedule input. | Calling the public key itself the session key. It is only input to shared secret derivation. |
| Server identity or PSK possession is authenticated. | Certificate, CertificateVerify, or PSK binder depending on credential mode. | Assuming encryption alone proves who is on the other side. |
| The transcript has not been silently changed. | Finished messages computed over the handshake transcript. | Ignoring Finished because it is small. It is the final integrity check before trusting the channel. |
| UDP path handles spoofing, replay, loss, and datagram boundaries. | DTLS cookie, record epoch, sequence numbers, ACK/retransmission, and fragmentation fields. | Thinking DTLS is just TLS with the TCP header removed. |
Quick reference
Compact facts learners can reuse
These cards keep the page useful after the animation, especially for independent review.
ClientHello
Offers supported_versions, cipher_suites, supported_groups, key_share, signature algorithms, SNI/ALPN, and optional PSK identities.
ServerHello
Selects a mutually supported path. In TLS 1.3, messages after ServerHello are protected by handshake traffic keys.
Key schedule
Shared secret inputs feed HKDF to produce handshake and application traffic secrets. The public key is not reused as the bulk data key.
CertificateVerify
The server signs the transcript context with its private key, binding the certificate identity to the selected handshake.
Finished
Both sides verify the full transcript before trusting application data. A mismatched transcript fails the handshake.
DTLS cookie
A stateless server cookie helps validate the claimed UDP source address before expensive state or cryptography is committed.
Credential choices
Certificates scale identity well; raw public keys reduce X.509 overhead; PSK can be compact but must be high entropy and provisioned safely.
TLS 1.2 caveat
ChangeCipherSpec and ServerKeyExchange belong to TLS 1.2-era flows. Do not use that message list as the main TLS 1.3 mental model.
Record layer
Handshake messages are carried in records. DTLS records add datagram-oriented epoch and sequence behavior for replay and reordering checks.
Guided practice
Use the workbench, then answer
These prompts force learners to connect the visible messages to security and deployment decisions.
Run the TLS 1.3 cert scenario. Which message changes the record protection state, and why can the certificate be encrypted in TLS 1.3?
Switch between certificate, raw public key, and PSK. Which option reduces bytes most, and what provisioning risk appears?
Run the DTLS cookie scenario with high loss. What does the cookie defend against, and what separate mechanism handles lost datagrams?
Collapsible deeper material
Technical guardrails
Keep these open when validating formulas, protocol labels, and IoT security claims.
TLS 1.3 key schedule guardrail
The animation uses a teaching trace, not live cryptographic output. The accurate relationship is that PSK and/or ephemeral (EC)DHE inputs feed HKDF extraction and expansion to produce early, handshake, application, exporter, and resumption-related secrets. It is not correct to say the ECDHE public key is the session key.
DTLS version guardrail
DTLS 1.3 follows the TLS 1.3 handshake shape where possible, but datagram transport adds record epochs, sequence numbers, replay handling, retransmission/ACK behavior, fragmentation handling, and optional cookie validation through HelloRetryRequest. Older DTLS 1.2 used a different HelloVerifyRequest shape; this page labels the modern cookie path as DTLS 1.3.
IoT credential guardrail
PSK mode can be bandwidth conserving, but a PSK must have enough entropy and must be provisioned and rotated safely. A serial number, password, or other predictable identifier is not a secure PSK. Raw public keys reduce certificate-chain bytes but still require a trustworthy binding between key and device identity.
What this animation deliberately does not claim
- It does not claim TLS protects a compromised endpoint after data is decrypted there.
- It does not claim all IoT deployments should use certificates; credential choice depends on manufacturing, identity scale, update policy, and threat model.
- It does not claim DTLS cookie validation prevents all denial-of-service attacks; it specifically reduces spoofed-source resource amplification before expensive server state is created.
Primary sources
Standards behind the workbench
The links below are the source material used for protocol labels and accuracy checks.
RFC 8446: TLS 1.3
Handshake, key schedule, cipher suite negotiation, CertificateVerify, Finished, and protected records.
RFC 9147: DTLS 1.3Datagram adaptation, cookie path, epochs, sequence numbers, ACK/retransmission, and fragmentation behavior.
RFC 7925: TLS/DTLS IoT profilesConstrained-device credential choices, PSK entropy cautions, raw public keys, and certificate considerations.
RFC 7252: CoAPApplication context for why constrained IoT deployments often pair UDP application protocols with DTLS.
Related animations