RFC 8446 · August 2018 · E. Rescorla
The Transport Layer Security (TLS) Protocol Version 1.3
Obsoleted by RFC 9846. Read the newer document for current behaviour.
Index fetched 2026-10-19 from rfc-editor.org
How it works
Built by hand from RFC 8446. Every arrow, step and field cites the RFC sentence it comes from, and an automated test checks each quote against the RFC text. Provisional: not yet reviewed by a second engineer. Help verify this visual
RFC 8446 §2 Figure 1 below shows the basic full TLS handshake:
1. Client → Server: ClientHello
The client opens with a random nonce, the protocol versions and cipher/hash pairs it offers, and Diffie-Hellman key shares and/or pre-shared key labels.
RFC 8446 §2Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* -------->
2. Server → Client: ServerHello
The server answers with the negotiated parameters: its own key_share for (EC)DHE, and/or pre_shared_key saying which offered PSK it picked. Everything after this is encrypted.
RFC 8446 §2ServerHello ^ Key + key_share* | Exch + pre_shared_key* v
3. Server → Client: EncryptedExtensions
Responses to the client's extensions that are not needed to pick the cryptographic parameters. Braces mean it is protected with handshake traffic keys.
RFC 8446 §2{EncryptedExtensions} ^ Server
4. Server → Client: CertificateRequest*
Sent only if the server wants the client to authenticate with a certificate; it carries the desired parameters for that certificate.
RFC 8446 §2{CertificateRequest*} v Params
5. Server → Client: Certificate*
The server's certificate. Omitted if the server is not authenticating with a certificate (for example, PSK mode).
RFC 8446 §2{Certificate*} ^ {CertificateVerify*} | Auth
6. Server → Client: CertificateVerify*
A signature over the entire handshake, made with the private key matching the certificate.
RFC 8446 §2{CertificateVerify*} | Auth {Finished} v
7. Server → Client: Finished
A MAC over the entire handshake. It provides key confirmation and binds the server's identity to the exchanged keys.
RFC 8446 §2{Finished} v <-------- [Application Data*]
8. Server → Client: [Application Data*]
The server may already send application data, but at this point it is sent to a peer that is not yet authenticated. Square brackets mean application traffic keys.
RFC 8446 §2<-------- [Application Data*]
9. Client → Server: Certificate*
The client's certificate, sent only if the server sent CertificateRequest.
RFC 8446 §2[Application Data*] ^ {Certificate*} Auth | {CertificateVerify*}
10. Client → Server: CertificateVerify*
The client's signature over the handshake, sent only when it authenticates with a certificate.
RFC 8446 §2Auth | {CertificateVerify*} v {Finished} -------->
11. Client → Server: Finished
The client's MAC over the handshake. The handshake is now complete; application data must not be sent before Finished (except as in Section 2.3).
RFC 8446 §2v {Finished} -------->
12. Client → Server: [Application Data]
Both sides now exchange application data protected with keys derived from the application traffic secrets.
RFC 8446 §2[Application Data] <-------> [Application Data]
Not shown: Server state machine (Appendix A.2), including the 0-RTT / WAIT_EOED path; Early data (0-RTT) and the 'Can send early data' window of the client state machine; PSK resumption and 0-RTT handshakes (Sections 2.2 and 2.3); Alerts and handshake failure: the Appendix A figures show no error transitions; Post-handshake messages: NewSessionTicket, KeyUpdate, post-handshake authentication; TLSCiphertext (protected record) layout and record protection (Section 5.2); Key schedule and extension details.
Lineage
Obsoletes (3)
Text
Loading the RFC text…