4. Handshake Protocol
The Handshake Protocol is used to negotiate the security parameters of a connection. Handshake messages are supplied to the TLS record layer, where they are encapsulated within one or more TLSPlaintext or TLSCiphertext structures which are processed and transmitted as specified by the current active connection state.
Note: Due to the extensive technical nature of this section (covering handshake message formats, extensions, and protocol flows), this document provides a structural overview. For complete technical specifications including all message structures, extension definitions, and protocol details, please refer to the official RFC 8446 document at https://www.rfc-editor.org/rfc/rfc8446.html
4.1. Key Exchange Messages
Key exchange messages are used to determine the security capabilities of the client and server and to establish shared secret material, including traffic keys used to protect the rest of the handshake and the data.
4.1.1. Cryptographic Negotiation
In TLS, cryptographic negotiation proceeds by the client offering four sets of options in the ClientHello:
- A list of cipher suites
- A "supported_groups" extension and a "key_share" extension
- A "signature_algorithms" extension
- A "pre_shared_key" extension and a "psk_key_exchange_modes" extension
4.1.2. Client Hello
The ClientHello message is the first TLS message sent by the client when connecting to a server.
Structure: The ClientHello message includes protocol version, random value, session ID, cipher suites, compression methods, and extensions.
4.1.3. Server Hello
The server sends this message in response to a ClientHello when it can find an acceptable set of parameters.
Structure: The ServerHello message includes protocol version, random value, session ID echo, cipher suite selection, compression method, and extensions.
4.1.4. Hello Retry Request
The server sends HelloRetryRequest to correct DHE share mismatches when needed.
4.2. Extensions
Many TLS messages contain tag-length-value encoded extensions. This section defines the format and usage of TLS extensions.
Extension Types: The specification defines numerous extensions including:
- supported_versions (4.2.1)
- cookie (4.2.2)
- signature_algorithms (4.2.3)
- certificate_authorities (4.2.4)
- oid_filters (4.2.5)
- post_handshake_auth (4.2.6)
- supported_groups (4.2.7)
- key_share (4.2.8)
- psk_key_exchange_modes (4.2.9)
- early_data (4.2.10)
- pre_shared_key (4.2.11)
4.3. Server Parameters
These messages establish handshake parameters that are not part of the key exchange:
- EncryptedExtensions (4.3.1)
- CertificateRequest (4.3.2)
4.4. Authentication Messages
TLS uses a common set of messages for authentication using asymmetric cryptography:
- Certificate (4.4.2)
- CertificateVerify (4.4.3)
- Finished (4.4.4)
4.5. End of Early Data
If the server has accepted early data, the client sends an EndOfEarlyData message after receiving the server Finished.
4.6. Post-Handshake Messages
TLS allows certain messages to be sent after the main handshake:
- New Session Ticket (4.6.1)
- Post-Handshake Authentication (4.6.2)
- Key and Initialization Vector Update (4.6.3)
Complete Technical Specification: For the complete and authoritative technical specifications including:
- Detailed message structure definitions
- All protocol data structures
- Complete extension specifications
- Security considerations for each component
- Implementation requirements
Please refer to RFC 8446 Sections 4.1 through 4.6 in the official document available at:
中文完整版本: 本文档的完整中文翻译版本可在以下路径查看：
i18n/zh-Hans/docusaurus-plugin-content-docs/current/rfc-8446/4.Handshake_Protocol.md