rfc-visual
GitHub

RFC 8446 · August 2018 · E. Rescorla

The Transport Layer Security (TLS) Protocol Version 1.3

PROPOSED STANDARDIETF stream

Obsoleted by RFC 9846. Read the newer document for current behaviour.

16 verified errata19 held for document update

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

100%

RFC 8446 §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 cipher/hash pairs it offers, and Diffie-Hellman key shares and/or pre-shared key labels.

    RFC 8446 §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 (EC)DHE, and/or pre_shared_key saying which offered PSK it picked. Everything after this is encrypted.

    RFC 8446 §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 8446 §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 8446 §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 8446 §2 {Certificate*} ^ {CertificateVerify*} | Auth
  6. 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. 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. 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. 9. Client → Server: Certificate*

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

    RFC 8446 §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 8446 §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 8446 §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 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

Text

Loading the RFC text…