Every HTTPS connection starts with a TLS handshake that agrees on keys and proves the server's identity. TLS 1.3 does this in a single round trip. This UML sequence diagram shows each handshake message, which ones are encrypted, and when application data can flow; a second diagram shows the slower HelloRetryRequest path.
1. The Diagram
Notation follows RFC 8446: plain names are cleartext, {braces} are encrypted with handshake keys, and [brackets] are encrypted with application keys.
ClientHello. The client lists cipher suites, sends supported_versions = TLS 1.3, the server name (SNI), ALPN (h2), and, crucially, an ECDHE key_share. Guessing the key exchange up front is what saves a round trip compared with TLS 1.2.
ServerHello. The server picks the cipher suite and returns its own key share. Both sides can now compute the shared secret and derive handshake keys.
Encrypted flight. Everything after ServerHello is encrypted: extensions, the certificate chain, a CertificateVerify signature proving possession of the private key, and Finished, a MAC over the whole transcript.
Client Finished. The client validates the chain and signature, checks the server's Finished, and sends its own. The handshake took one round trip.
Application data. The HTTP request can ride directly behind the client's Finished. The server may later send a NewSessionTicket for resumption.
2. How to Read It
Yellow arrows are the two cleartext hello messages; blue arrows are encrypted handshake records; green arrows carry application data. Dashed boxes group each flight, which is a set of messages sent back-to-back without waiting.
3. Variant: HelloRetryRequest
If the client's key share uses a group the server does not accept, the server answers with HelloRetryRequest naming a group it supports. The client retries, and the handshake costs two round trips. Clients avoid this by offering the most widely supported group (x25519) first.
4. Pros, Cons, and When to Use
Pros
Makes the round-trip count obvious, which is the main reason TLS 1.3 is faster.
Shows exactly which messages are visible to an observer and which are encrypted.
Lines up with openssl s_client -msg or a Wireshark TLS trace.
Fragments separate flights clearly.
Good for security reviews: where is the server authenticated?
Cons
Omits the key schedule; the derivations need a separate figure.
Records, padding and fragmentation are invisible.
Does not show the TCP (or QUIC) handshake underneath unless you add it.
Optional paths (client certs, PSK, 0-RTT) quickly clutter it.
When to use
Explaining handshake latency, TLS termination or mTLS design.
Certificate hierarchy questions (draw a trust-chain tree).
Where TLS terminates in your architecture (use a topology diagram).
5. As Diagrams-as-Code
PlantUML sequence diagram:
@startuml
participant Client
participant "Server\napi.example.com" as S
group flight 1 (cleartext)
Client -> S : ClientHello + key_share + SNI + ALPN
S -> Client : ServerHello + key_share
end
note over Client, S : derive handshake keys (ECDHE)
group flight 2 (handshake keys)
S -> Client : {EncryptedExtensions}
S -> Client : {Certificate}
S -> Client : {CertificateVerify}
S -> Client : {Finished}
end
Client -> S : {Finished}
Client -> S : [HTTP request]
S -> Client : [HTTP response]
S --> Client : [NewSessionTicket]
@enduml