rfc-visual
GitHub

RFC 9846 · July 2026 · E. Rescorla

The Transport Layer Security (TLS) Protocol Version 1.3

PROPOSED STANDARDIETF stream
1 verified errata4 reported (unverified)

Index fetched 2026-10-19 from rfc-editor.org

How it works

Built by hand from RFC 9846. 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 maintainer. Help verify this visual

100%

RFC 9846 §2 Figure 1 below shows the basic full TLS handshake:

  1. 1. Client → Server: ClientHello

    The client opens with a random nonce, the protocol versions and symmetric cipher/hash pairs it offers, and asymmetric key exchange shares and/or pre-shared key labels.

    RFC 9846 §2 Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* v + pre_shared_key* -------->
  2. 2. Server → Client: ServerHello

    The server answers with the negotiated parameters: its own key_share for asymmetric key exchange, and/or pre_shared_key saying which offered PSK it picked. Everything after this is encrypted.

    RFC 9846 §2 ServerHello ^ Key + key_share* | Exch + pre_shared_key* v
  3. 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 9846 §2 {EncryptedExtensions} ^ Server
  4. 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 9846 §2 {CertificateRequest*} v Params
  5. 5. Server → Client: Certificate*

    The server's certificate. Omitted if the server is not authenticating with a certificate (for example, PSK mode).

    RFC 9846 §2 {Certificate*} ^ {CertificateVerify*} | Auth
  6. 6. Server → Client: CertificateVerify*

    A signature over the entire handshake, made with the private key matching the certificate.

    RFC 9846 §2 {CertificateVerify*} | Auth {Finished} v
  7. 7. Server → Client: Finished

    A MAC over the entire handshake. It provides key confirmation for the shared secrets and binds the server's identity to the exchanged keys.

    RFC 9846 §2 {Finished} v <-------- [Application Data*]
  8. 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 9846 §2 <-------- [Application Data*]
  9. 9. Client → Server: Certificate*

    The client's certificate, sent only if the server sent CertificateRequest.

    RFC 9846 §2 [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*}
  10. 10. Client → Server: CertificateVerify*

    The client's signature over the handshake, sent only when it authenticates with a certificate.

    RFC 9846 §2 Auth | {CertificateVerify*} v {Finished} -------->
  11. 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 9846 §2 v {Finished} -------->
  12. 12. Client → Server: [Application Data]

    Both sides now exchange application data protected with keys derived from the application traffic secrets.

    RFC 9846 §2 [Application Data] <-------> [Application Data]

Quoted text consists of unmodified excerpts from RFC 9846, published by the IETF (line breaks reflowed). Copyright in the RFC text belongs to the IETF Trust and the persons identified as the document authors, as stated in the RFC. The diagrams and plain-English explanations are rfc-visual's own and do not replace the RFC.

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; Key-encapsulation mechanisms (KEMs) for asymmetric key exchange, which Section 2 says other extensions define.

Lineage

Text

Loading the RFC text…