Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 8446 Mozilla
Obsoletes: 5077, 5246, 6961 August 2018
Updates: 5705, 6066
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) E. Rescorla
Request for Comments: 8446 Mozilla
Obsoletes: 5077, 5246, 6961 August 2018
Updates: 5705, 6066
Category: Standards Track
ISSN: 2070-1721
The Transport Layer Security (TLS) Protocol Version 1.3
传输层安全（TLS）协议版本1.3
Abstract
摘要
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
本文件规定了传输层安全（TLS）协议的1.3版。TLS允许客户机/服务器应用程序通过Internet进行通信，这种通信方式旨在防止窃听、篡改和消息伪造。
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
本文档更新了RFCs 5705和6066，并淘汰了RFCs 5077、5246和6961。本文件还规定了TLS 1.2实施的新要求。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8446.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8446.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................6
1.1. Conventions and Terminology ................................7
1.2. Major Differences from TLS 1.2 .............................8
1.3. Updates Affecting TLS 1.2 ..................................9
2. Protocol Overview ..............................................10
2.1. Incorrect DHE Share .......................................14
2.2. Resumption and Pre-Shared Key (PSK) .......................15
2.3. 0-RTT Data ................................................17
3. Presentation Language ..........................................19
3.1. Basic Block Size ..........................................19
3.2. Miscellaneous .............................................20
3.3. Numbers ...................................................20
3.4. Vectors ...................................................20
3.5. Enumerateds ...............................................21
3.6. Constructed Types .........................................22
3.7. Constants .................................................23
3.8. Variants ..................................................23
4. Handshake Protocol .............................................24
4.1. Key Exchange Messages .....................................25
4.1.1. Cryptographic Negotiation ..........................26
4.1.2. Client Hello .......................................27
4.1.3. Server Hello .......................................31
4.1.4. Hello Retry Request ................................33
4.2. Extensions ................................................35
4.2.1. Supported Versions .................................39
4.2.2. Cookie .............................................40
4.2.3. Signature Algorithms ...............................41
4.2.4. Certificate Authorities ............................45
4.2.5. OID Filters ........................................45
4.2.6. Post-Handshake Client Authentication ...............47
4.2.7. Supported Groups ...................................47
4.2.8. Key Share ..........................................48
4.2.9. Pre-Shared Key Exchange Modes ......................51
4.2.10. Early Data Indication .............................52
4.2.11. Pre-Shared Key Extension ..........................55
4.3. Server Parameters .........................................59
4.3.1. Encrypted Extensions ...............................60
4.3.2. Certificate Request ................................60
4.4. Authentication Messages ...................................61
4.4.1. The Transcript Hash ................................63
4.4.2. Certificate ........................................64
4.4.3. Certificate Verify .................................69
4.4.4. Finished ...........................................71
4.5. End of Early Data .........................................72
1. Introduction ....................................................6
1.1. Conventions and Terminology ................................7
1.2. Major Differences from TLS 1.2 .............................8
1.3. Updates Affecting TLS 1.2 ..................................9
2. Protocol Overview ..............................................10
2.1. Incorrect DHE Share .......................................14
2.2. Resumption and Pre-Shared Key (PSK) .......................15
2.3. 0-RTT Data ................................................17
3. Presentation Language ..........................................19
3.1. Basic Block Size ..........................................19
3.2. Miscellaneous .............................................20
3.3. Numbers ...................................................20
3.4. Vectors ...................................................20
3.5. Enumerateds ...............................................21
3.6. Constructed Types .........................................22
3.7. Constants .................................................23
3.8. Variants ..................................................23
4. Handshake Protocol .............................................24
4.1. Key Exchange Messages .....................................25
4.1.1. Cryptographic Negotiation ..........................26
4.1.2. Client Hello .......................................27
4.1.3. Server Hello .......................................31
4.1.4. Hello Retry Request ................................33
4.2. Extensions ................................................35
4.2.1. Supported Versions .................................39
4.2.2. Cookie .............................................40
4.2.3. Signature Algorithms ...............................41
4.2.4. Certificate Authorities ............................45
4.2.5. OID Filters ........................................45
4.2.6. Post-Handshake Client Authentication ...............47
4.2.7. Supported Groups ...................................47
4.2.8. Key Share ..........................................48
4.2.9. Pre-Shared Key Exchange Modes ......................51
4.2.10. Early Data Indication .............................52
4.2.11. Pre-Shared Key Extension ..........................55
4.3. Server Parameters .........................................59
4.3.1. Encrypted Extensions ...............................60
4.3.2. Certificate Request ................................60
4.4. Authentication Messages ...................................61
4.4.1. The Transcript Hash ................................63
4.4.2. Certificate ........................................64
4.4.3. Certificate Verify .................................69
4.4.4. Finished ...........................................71
4.5. End of Early Data .........................................72
4.6. Post-Handshake Messages ...................................73
4.6.1. New Session Ticket Message .........................73
4.6.2. Post-Handshake Authentication ......................75
4.6.3. Key and Initialization Vector Update ...............76
5. Record Protocol ................................................77
5.1. Record Layer ..............................................78
5.2. Record Payload Protection .................................80
5.3. Per-Record Nonce ..........................................82
5.4. Record Padding ............................................83
5.5. Limits on Key Usage .......................................84
6. Alert Protocol .................................................85
6.1. Closure Alerts ............................................87
6.2. Error Alerts ..............................................88
7. Cryptographic Computations .....................................90
7.1. Key Schedule ..............................................91
7.2. Updating Traffic Secrets ..................................94
7.3. Traffic Key Calculation ...................................95
7.4. (EC)DHE Shared Secret Calculation .........................95
7.4.1. Finite Field Diffie-Hellman ........................95
7.4.2. Elliptic Curve Diffie-Hellman ......................96
7.5. Exporters .................................................97
8. 0-RTT and Anti-Replay ..........................................98
8.1. Single-Use Tickets ........................................99
8.2. Client Hello Recording ....................................99
8.3. Freshness Checks .........................................101
9. Compliance Requirements .......................................102
9.1. Mandatory-to-Implement Cipher Suites .....................102
9.2. Mandatory-to-Implement Extensions ........................103
9.3. Protocol Invariants ......................................104
10. Security Considerations ......................................106
11. IANA Considerations ..........................................106
12. References ...................................................109
12.1. Normative References ....................................109
12.2. Informative References ..................................112
Appendix A. State Machine ........................................120
A.1. Client ....................................................120
A.2. Server ....................................................121
Appendix B. Protocol Data Structures and Constant Values .........122
B.1. Record Layer ..............................................122
B.2. Alert Messages ............................................123
B.3. Handshake Protocol ........................................124
B.3.1. Key Exchange Messages .................................125
B.3.2. Server Parameters Messages ............................131
B.3.3. Authentication Messages ...............................132
B.3.4. Ticket Establishment ..................................132
B.3.5. Updating Keys .........................................133
B.4. Cipher Suites .............................................133
4.6. Post-Handshake Messages ...................................73
4.6.1. New Session Ticket Message .........................73
4.6.2. Post-Handshake Authentication ......................75
4.6.3. Key and Initialization Vector Update ...............76
5. Record Protocol ................................................77
5.1. Record Layer ..............................................78
5.2. Record Payload Protection .................................80
5.3. Per-Record Nonce ..........................................82
5.4. Record Padding ............................................83
5.5. Limits on Key Usage .......................................84
6. Alert Protocol .................................................85
6.1. Closure Alerts ............................................87
6.2. Error Alerts ..............................................88
7. Cryptographic Computations .....................................90
7.1. Key Schedule ..............................................91
7.2. Updating Traffic Secrets ..................................94
7.3. Traffic Key Calculation ...................................95
7.4. (EC)DHE Shared Secret Calculation .........................95
7.4.1. Finite Field Diffie-Hellman ........................95
7.4.2. Elliptic Curve Diffie-Hellman ......................96
7.5. Exporters .................................................97
8. 0-RTT and Anti-Replay ..........................................98
8.1. Single-Use Tickets ........................................99
8.2. Client Hello Recording ....................................99
8.3. Freshness Checks .........................................101
9. Compliance Requirements .......................................102
9.1. Mandatory-to-Implement Cipher Suites .....................102
9.2. Mandatory-to-Implement Extensions ........................103
9.3. Protocol Invariants ......................................104
10. Security Considerations ......................................106
11. IANA Considerations ..........................................106
12. References ...................................................109
12.1. Normative References ....................................109
12.2. Informative References ..................................112
Appendix A. State Machine ........................................120
A.1. Client ....................................................120
A.2. Server ....................................................121
Appendix B. Protocol Data Structures and Constant Values .........122
B.1. Record Layer ..............................................122
B.2. Alert Messages ............................................123
B.3. Handshake Protocol ........................................124
B.3.1. Key Exchange Messages .................................125
B.3.2. Server Parameters Messages ............................131
B.3.3. Authentication Messages ...............................132
B.3.4. Ticket Establishment ..................................132
B.3.5. Updating Keys .........................................133
B.4. Cipher Suites .............................................133
Appendix C. Implementation Notes .................................134
C.1. Random Number Generation and Seeding ......................134
C.2. Certificates and Authentication ...........................135
C.3. Implementation Pitfalls ...................................135
C.4. Client Tracking Prevention ................................137
C.5. Unauthenticated Operation .................................137
Appendix D. Backward Compatibility ...............................138
D.1. Negotiating with an Older Server ..........................139
D.2. Negotiating with an Older Client ..........................139
D.3. 0-RTT Backward Compatibility ..............................140
D.4. Middlebox Compatibility Mode ..............................140
D.5. Security Restrictions Related to Backward Compatibility ...141
Appendix E. Overview of Security Properties ......................142
E.1. Handshake .................................................142
E.1.1. Key Derivation and HKDF ...............................145
E.1.2. Client Authentication .................................146
E.1.3. 0-RTT .................................................146
E.1.4. Exporter Independence .................................146
E.1.5. Post-Compromise Security ..............................146
E.1.6. External References ...................................147
E.2. Record Layer ..............................................147
E.2.1. External References ...................................148
E.3. Traffic Analysis ..........................................148
E.4. Side-Channel Attacks ......................................149
E.5. Replay Attacks on 0-RTT ...................................150
E.5.1. Replay and Exporters ..................................151
E.6. PSK Identity Exposure .....................................152
E.7. Sharing PSKs ..............................................152
E.8. Attacks on Static RSA .....................................152
Contributors .....................................................153
Author's Address .................................................160
Appendix C. Implementation Notes .................................134
C.1. Random Number Generation and Seeding ......................134
C.2. Certificates and Authentication ...........................135
C.3. Implementation Pitfalls ...................................135
C.4. Client Tracking Prevention ................................137
C.5. Unauthenticated Operation .................................137
Appendix D. Backward Compatibility ...............................138
D.1. Negotiating with an Older Server ..........................139
D.2. Negotiating with an Older Client ..........................139
D.3. 0-RTT Backward Compatibility ..............................140
D.4. Middlebox Compatibility Mode ..............................140
D.5. Security Restrictions Related to Backward Compatibility ...141
Appendix E. Overview of Security Properties ......................142
E.1. Handshake .................................................142
E.1.1. Key Derivation and HKDF ...............................145
E.1.2. Client Authentication .................................146
E.1.3. 0-RTT .................................................146
E.1.4. Exporter Independence .................................146
E.1.5. Post-Compromise Security ..............................146
E.1.6. External References ...................................147
E.2. Record Layer ..............................................147
E.2.1. External References ...................................148
E.3. Traffic Analysis ..........................................148
E.4. Side-Channel Attacks ......................................149
E.5. Replay Attacks on 0-RTT ...................................150
E.5.1. Replay and Exporters ..................................151
E.6. PSK Identity Exposure .....................................152
E.7. Sharing PSKs ..............................................152
E.8. Attacks on Static RSA .....................................152
Contributors .....................................................153
Author's Address .................................................160
The primary goal of TLS is to provide a secure channel between two communicating peers; the only requirement from the underlying transport is a reliable, in-order data stream. Specifically, the secure channel should provide the following properties:
TLS的主要目标是在两个通信对等点之间提供安全通道；底层传输的唯一要求是可靠、有序的数据流。具体而言，安全通道应提供以下属性：
- Authentication: The server side of the channel is always authenticated; the client side is optionally authenticated. Authentication can happen via asymmetric cryptography (e.g., RSA [RSA], the Elliptic Curve Digital Signature Algorithm (ECDSA) [ECDSA], or the Edwards-Curve Digital Signature Algorithm (EdDSA) [RFC8032]) or a symmetric pre-shared key (PSK).
- 身份验证：通道的服务器端始终经过身份验证；客户端可以选择进行身份验证。身份验证可以通过非对称加密（例如RSA[RSA]、椭圆曲线数字签名算法（ECDSA）[ECDSA]或爱德华兹曲线数字签名算法（EdDSA）[RFC8032]）或对称预共享密钥（PSK）进行。
- Confidentiality: Data sent over the channel after establishment is only visible to the endpoints. TLS does not hide the length of the data it transmits, though endpoints are able to pad TLS records in order to obscure lengths and improve protection against traffic analysis techniques.
- 机密性：建立后通过通道发送的数据仅对端点可见。TLS不会隐藏它传输的数据的长度，尽管端点能够填充TLS记录，以隐藏长度并改进对流量分析技术的保护。
- Integrity: Data sent over the channel after establishment cannot be modified by attackers without detection.
- 完整性：建立后通过通道发送的数据在未经检测的情况下无法被攻击者修改。
These properties should be true even in the face of an attacker who has complete control of the network, as described in [RFC3552]. See Appendix E for a more complete statement of the relevant security properties.
如[RFC3552]所述，即使面对完全控制网络的攻击者，这些属性也应为真。有关相关安全属性的更完整说明，请参见附录E。
TLS consists of two primary components:
TLS由两个主要组件组成：
- A handshake protocol (Section 4) that authenticates the communicating parties, negotiates cryptographic modes and parameters, and establishes shared keying material. The handshake protocol is designed to resist tampering; an active attacker should not be able to force the peers to negotiate different parameters than they would if the connection were not under attack.
- 一种握手协议（第4节），用于认证通信双方，协商加密模式和参数，并建立共享密钥材料。握手协议设计为抗篡改；主动攻击者不应强迫对等方协商与连接未受到攻击时不同的参数。
- A record protocol (Section 5) that uses the parameters established by the handshake protocol to protect traffic between the communicating peers. The record protocol divides traffic up into a series of records, each of which is independently protected using the traffic keys.
- 一种记录协议（第5节），使用握手协议建立的参数来保护通信对等方之间的通信。记录协议将流量分成一系列记录，每个记录都使用流量密钥进行独立保护。
TLS is application protocol independent; higher-level protocols can layer on top of TLS transparently. The TLS standard, however, does not specify how protocols add security with TLS; how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS.
TLS与应用协议无关；高层协议可以透明地在TLS之上分层。然而，TLS标准没有规定协议如何增加TLS的安全性；如何启动TLS握手以及如何解释交换的身份验证证书将留给运行在TLS之上的协议的设计者和实现者来判断。
This document defines TLS version 1.3. While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a versioning mechanism which allows clients and servers to interoperably negotiate a common version if one is supported by both peers.
本文件定义了TLS 1.3版。虽然TLS 1.3与以前的版本不直接兼容，但TLS的所有版本都包含一个版本控制机制，允许客户端和服务器在两个对等方都支持的情况下互操作协商一个公共版本。
This document supersedes and obsoletes previous versions of TLS, including version 1.2 [RFC5246]. It also obsoletes the TLS ticket mechanism defined in [RFC5077] and replaces it with the mechanism defined in Section 2.2. Because TLS 1.3 changes the way keys are derived, it updates [RFC5705] as described in Section 7.5. It also changes how Online Certificate Status Protocol (OCSP) messages are carried and therefore updates [RFC6066] and obsoletes [RFC6961] as described in Section 4.4.2.1.
本文件取代并废弃了TLS的早期版本，包括1.2版[RFC5246]。它还废弃了[RFC5077]中定义的TLS票证机制，并将其替换为第2.2节中定义的机制。由于TLS 1.3更改了密钥的导出方式，因此它会更新[RFC5705]，如第7.5节所述。它还改变了在线证书状态协议（OCSP）消息的传输方式，因此更新[RFC6066]并淘汰[RFC6961]，如第4.4.2.1节所述。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The following terms are used:
使用以下术语：
client: The endpoint initiating the TLS connection.
客户端：启动TLS连接的端点。
connection: A transport-layer connection between two endpoints.
连接：两个端点之间的传输层连接。
endpoint: Either the client or server of the connection.
端点：连接的客户端或服务器。
handshake: An initial negotiation between client and server that establishes the parameters of their subsequent interactions within TLS.
握手：客户机和服务器之间的初始协商，用于确定TLS中后续交互的参数。
peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is not the primary subject of discussion.
对等：端点。讨论特定端点时，“对等点”指的是不是主要讨论主题的端点。
receiver: An endpoint that is receiving records.
receiver：接收记录的端点。
sender: An endpoint that is transmitting records.
发送方：传输记录的端点。
server: The endpoint that did not initiate the TLS connection.
服务器：未启动TLS连接的终结点。
The following is a list of the major functional differences between TLS 1.2 and TLS 1.3. It is not intended to be exhaustive, and there are many minor differences.
以下列出了TLS 1.2和TLS 1.3之间的主要功能差异。本文件并非详尽无遗，其中有许多细微差别。
- The list of supported symmetric encryption algorithms has been pruned of all algorithms that are considered legacy. Those that remain are all Authenticated Encryption with Associated Data (AEAD) algorithms. The cipher suite concept has been changed to separate the authentication and key exchange mechanisms from the record protection algorithm (including secret key length) and a hash to be used with both the key derivation function and handshake message authentication code (MAC).
- 受支持的对称加密算法列表已删除所有被视为遗留的算法。剩下的都是使用关联数据（AEAD）算法进行身份验证的加密。密码套件的概念已经改变，以将身份验证和密钥交换机制与记录保护算法（包括密钥长度）以及与密钥派生函数和握手消息身份验证码（MAC）一起使用的散列分开。
- A zero round-trip time (0-RTT) mode was added, saving a round trip at connection setup for some application data, at the cost of certain security properties.
- 添加了零往返时间（0-RTT）模式，以牺牲某些安全属性为代价，在连接设置时为某些应用程序数据节省了往返时间。
- Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
- 已删除静态RSA和Diffie-Hellman密码套件；所有基于公钥的密钥交换机制现在都提供前向保密性。
- All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtensions message allows various extensions previously sent in the clear in the ServerHello to also enjoy confidentiality protection.
- ServerHello之后的所有握手消息现在都已加密。新引入的EncryptedExtensions消息允许以前在服务器Hello中以明文形式发送的各种扩展也可以享受保密保护。
- The key derivation functions have been redesigned. The new design allows easier analysis by cryptographers due to their improved key separation properties. The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is used as an underlying primitive.
- 对关键的派生函数进行了重新设计。由于改进了密钥分离特性，新设计使得密码学家更容易进行分析。基于HMAC的提取和扩展密钥派生函数（HKDF）用作底层原语。
- The handshake state machine has been significantly restructured to be more consistent and to remove superfluous messages such as ChangeCipherSpec (except when needed for middlebox compatibility).
- 握手状态机经过了显著的重组，使其更加一致，并删除了诸如ChangeCipherSpec之类的多余消息（除非出于中间盒兼容性的需要）。
- Elliptic curve algorithms are now in the base spec, and new signature algorithms, such as EdDSA, are included. TLS 1.3 removed point format negotiation in favor of a single point format for each curve.
- 椭圆曲线算法现在已列入基本规范，并包括新的签名算法，如EdDSA。TLS 1.3删除了点格式协商，支持每条曲线的单点格式。
- Other cryptographic improvements were made, including changing the RSA padding to use the RSA Probabilistic Signature Scheme (RSASSA-PSS), and the removal of compression, the Digital Signature Algorithm (DSA), and custom Ephemeral Diffie-Hellman (DHE) groups.
- 还进行了其他加密改进，包括将RSA填充改为使用RSA概率签名方案（RSASSA-PSS），以及删除压缩、数字签名算法（DSA）和自定义瞬时Diffie-Hellman（DHE）组。
- The TLS 1.2 version negotiation mechanism has been deprecated in favor of a version list in an extension. This increases compatibility with existing servers that incorrectly implemented version negotiation.
- TLS 1.2版本协商机制已被弃用，取而代之的是扩展中的版本列表。这增加了与未正确实施版本协商的现有服务器的兼容性。
- Session resumption with and without server-side state as well as the PSK-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange.
- 具有或不具有服务器端状态的会话恢复以及早期TLS版本的基于PSK的密码套件已被一个新的PSK exchange所取代。
- References have been updated to point to the updated versions of RFCs, as appropriate (e.g., RFC 5280 rather than RFC 3280).
- 参考文献已更新，以指出RFC的更新版本（如RFC 5280而非RFC 3280）。
This document defines several changes that optionally affect implementations of TLS 1.2, including those which do not also support TLS 1.3:
本文档定义了一些可能影响TLS 1.2实施的变更，包括不支持TLS 1.3的变更：
- A version downgrade protection mechanism is described in Section 4.1.3.
- 版本降级保护机制见第4.1.3节。
- RSASSA-PSS signature schemes are defined in Section 4.2.3.
- 第4.2.3节定义了RSASSA-PSS签名方案。
- The "supported_versions" ClientHello extension can be used to negotiate the version of TLS to use, in preference to the legacy_version field of the ClientHello.
- “supported_versions”ClientHello扩展可用于协商要使用的TLS版本，优先于ClientHello的legacy_version字段。
- The "signature_algorithms_cert" extension allows a client to indicate which signature algorithms it can validate in X.509 certificates.
- “signature\u algorithms\u cert”扩展允许客户端指示它可以在X.509证书中验证哪些签名算法。
Additionally, this document clarifies some compliance requirements for earlier versions of TLS; see Section 9.3.
此外，本文件澄清了TLS早期版本的一些合规要求；见第9.3节。
The cryptographic parameters used by the secure channel are produced by the TLS handshake protocol. This sub-protocol of TLS is used by the client and server when first communicating with each other. The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material. Once the handshake is complete, the peers use the established keys to protect the application-layer traffic.
安全通道使用的加密参数由TLS握手协议生成。TLS的这个子协议在客户端和服务器首次相互通信时使用。握手协议允许对等方协商协议版本、选择加密算法、选择性地相互验证以及建立共享密钥材料。握手完成后，对等方使用已建立的密钥来保护应用层通信。
A failure of the handshake or other protocol error triggers the termination of the connection, optionally preceded by an alert message (Section 6).
握手失败或其他协议错误会触发连接终止，之前可能会显示警报消息（第6节）。
TLS supports three basic key exchange modes:
TLS支持三种基本密钥交换模式：
- (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
- （EC）DHE（有限域或椭圆曲线上的Diffie-Hellman）
- PSK-only
- 仅限PSK
- PSK with (EC)DHE
- PSK与（EC）DHE
Figure 1 below shows the basic full TLS handshake:
下图1显示了基本的完整TLS握手：
Client Server
客户端服务器
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
Key ^ ClientHello
Exch | + key_share*
| + signature_algorithms*
| + psk_key_exchange_modes*
v + pre_shared_key* -------->
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the previously noted message.
+ 指示在先前注意到的消息中发送的值得注意的扩展。
* Indicates optional or situation-dependent messages/extensions that are not always sent.
* 指示不总是发送的可选或依赖于情况的消息/扩展。
{} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret.
{}表示使用从[发送方]\u握手\u通信\u秘密派生的密钥保护的消息。
[] Indicates messages protected using keys derived from [sender]_application_traffic_secret_N.
[]表示使用从[发件人]\u应用程序\u流量\u机密\u派生的密钥保护的邮件。
Figure 1: Message Flow for Full TLS Handshake
图1：完整TLS握手的消息流
The handshake can be thought of as having three phases (indicated in the diagram above):
握手可以被认为有三个阶段（如上图所示）：
- Key Exchange: Establish shared keying material and select the cryptographic parameters. Everything after this phase is encrypted.
- 密钥交换：建立共享密钥材料并选择加密参数。此阶段之后的所有内容都是加密的。
- Server Parameters: Establish other handshake parameters (whether the client is authenticated, application-layer protocol support, etc.).
- 服务器参数：建立其他握手参数（客户端是否经过身份验证、应用层协议支持等）。
- Authentication: Authenticate the server (and, optionally, the client) and provide key confirmation and handshake integrity.
- 身份验证：对服务器（以及可选的客户端）进行身份验证，并提供密钥确认和握手完整性。
In the Key Exchange phase, the client sends the ClientHello (Section 4.1.2) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key shares (in the "key_share" (Section 4.2.8) extension), a set of pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) extension), or both; and potentially additional extensions. Additional fields and/or messages may also be present for middlebox compatibility.
在密钥交换阶段，客户端发送ClientHello（第4.1.2节）消息，其中包含一个随机nonce（ClientHello.random）；其提供的协议版本；对称密码/HKDF哈希对列表；一组Diffie-Hellman密钥共享（在“密钥共享”（第4.2.8节）扩展中）、一组预共享密钥标签（在“预共享密钥”（第4.2.11节）扩展中）或两者；以及潜在的额外扩展。还可能存在其他字段和/或消息，以实现中间盒兼容性。
The server processes the ClientHello and determines the appropriate cryptographic parameters for the connection. It then responds with its own ServerHello (Section 4.1.3), which indicates the negotiated connection parameters. The combination of the ClientHello and the ServerHello determines the shared keys. If (EC)DHE key establishment is in use, then the ServerHello contains a "key_share" extension with the server's ephemeral Diffie-Hellman share; the server's share MUST be in the same group as one of the client's shares. If PSK key establishment is in use, then the ServerHello contains a "pre_shared_key" extension indicating which of the client's offered PSKs was selected. Note that implementations can use (EC)DHE and PSK together, in which case both extensions will be supplied.
服务器处理ClientHello并为连接确定适当的加密参数。然后，它使用自己的ServerHello（第4.1.3节）进行响应，这表示协商的连接参数。ClientHello和ServerHello的组合决定了共享密钥。如果（EC）DHE密钥建立正在使用中，那么ServerHello包含一个带有服务器短暂Diffie Hellman共享的“密钥共享”扩展；服务器共享必须与客户端共享之一位于同一组中。如果正在使用PSK密钥建立，则ServerHello包含一个“pre_shared_key”扩展，指示选择了客户端提供的PSK。注意，实现可以同时使用（EC）DHE和PSK，在这种情况下，将提供两个扩展。
The server then sends two messages to establish the Server Parameters:
然后，服务器发送两条消息以建立服务器参数：
EncryptedExtensions: responses to ClientHello extensions that are not required to determine the cryptographic parameters, other than those that are specific to individual certificates. [Section 4.3.1]
EncryptedExtensions：对ClientHello扩展的响应，这些扩展不需要确定加密参数，但特定于单个证书的参数除外。[第4.3.1节]
CertificateRequest: if certificate-based client authentication is desired, the desired parameters for that certificate. This message is omitted if client authentication is not desired. [Section 4.3.2]
CertificateRequest：如果需要基于证书的客户端身份验证，则需要该证书的所需参数。如果不需要客户端身份验证，则忽略此消息。[第4.3.2节]
Finally, the client and server exchange Authentication messages. TLS uses the same set of messages every time that certificate-based authentication is needed. (PSK-based authentication happens as a side effect of key exchange.) Specifically:
最后，客户端和服务器交换身份验证消息。每次需要基于证书的身份验证时，TLS都使用相同的消息集。（基于PSK的身份验证是密钥交换的副作用。）具体来说：
Certificate: The certificate of the endpoint and any per-certificate extensions. This message is omitted by the server if not authenticating with a certificate and by the client if the server did not send CertificateRequest (thus indicating that the client should not authenticate with a certificate). Note that if raw public keys [RFC7250] or the cached information extension [RFC7924] are in use, then this message will not contain a certificate but rather some other value corresponding to the server's long-term key. [Section 4.4.2]
证书：端点的证书和任何每证书扩展。如果服务器未使用证书进行身份验证，则服务器会忽略此消息；如果服务器未发送CertificateRequest，则客户端会忽略此消息（从而指示客户端不应使用证书进行身份验证）。请注意，如果使用原始公钥[RFC7250]或缓存信息扩展[RFC7924]，则此消息将不包含证书，而是包含与服务器的长期密钥相对应的其他值。[第4.4.2节]
CertificateVerify: A signature over the entire handshake using the private key corresponding to the public key in the Certificate message. This message is omitted if the endpoint is not authenticating via a certificate. [Section 4.4.3]
CertificateVerify：在整个握手过程中使用与证书消息中的公钥对应的私钥进行签名。如果端点未通过证书进行身份验证，则忽略此消息。[第4.4.3节]
Finished: A MAC (Message Authentication Code) over the entire handshake. This message provides key confirmation, binds the endpoint's identity to the exchanged keys, and in PSK mode also authenticates the handshake. [Section 4.4.4]
完成：整个握手过程中的MAC（消息身份验证码）。此消息提供密钥确认，将端点的标识绑定到交换的密钥，并且在PSK模式下还对握手进行身份验证。[第4.4.4节]
Upon receiving the server's messages, the client responds with its Authentication messages, namely Certificate and CertificateVerify (if requested), and Finished.
在接收到服务器的消息后，客户端用其身份验证消息（即Certificate和CertificateVerify（如果请求））进行响应，并完成。
At this point, the handshake is complete, and the client and server derive the keying material required by the record layer to exchange application-layer data protected through authenticated encryption. Application Data MUST NOT be sent prior to sending the Finished message, except as specified in Section 2.3. Note that while the server may send Application Data prior to receiving the client's Authentication messages, any data sent at that point is, of course, being sent to an unauthenticated peer.
此时，握手完成，客户机和服务器获得记录层所需的密钥材料，以交换通过身份验证加密保护的应用层数据。除非第2.3节另有规定，否则在发送完成的消息之前不得发送应用程序数据。请注意，虽然服务器可以在接收客户端的身份验证消息之前发送应用程序数据，但此时发送的任何数据当然都会被发送到未经身份验证的对等方。
If the client has not provided a sufficient "key_share" extension (e.g., it includes only DHE or ECDHE groups unacceptable to or unsupported by the server), the server corrects the mismatch with a HelloRetryRequest and the client needs to restart the handshake with an appropriate "key_share" extension, as shown in Figure 2. If no common cryptographic parameters can be negotiated, the server MUST abort the handshake with an appropriate alert.
如果客户端没有提供足够的“密钥共享”扩展（例如，它只包括服务器不可接受或不支持的DHE或ECDHE组），服务器将纠正与HelloRetryRequest的不匹配，客户端需要使用适当的“密钥共享”扩展重新启动握手，如图2所示。如果无法协商通用加密参数，服务器必须使用适当的警报中止握手。
Client Server
客户端服务器
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
ClientHello
+ key_share -------->
HelloRetryRequest
<-------- + key_share
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: Message Flow for a Full Handshake with Mismatched Parameters
图2：参数不匹配的完整握手的消息流
Note: The handshake transcript incorporates the initial ClientHello/HelloRetryRequest exchange; it is not reset with the new ClientHello.
注：握手记录包含最初的ClientHello/HelloRetryRequest交换；它不会用新的ClientHello重置。
TLS also allows several optimized variants of the basic handshake, as described in the following sections.
TLS还允许基本握手的几种优化变体，如以下部分所述。
Although TLS PSKs can be established out of band, PSKs can also be established in a previous connection and then used to establish a new connection ("session resumption" or "resuming" with a PSK). Once a handshake has completed, the server can send the client a PSK identity that corresponds to a unique key derived from the initial handshake (see Section 4.6.1). The client can then use that PSK identity in future handshakes to negotiate the use of the associated PSK. If the server accepts the PSK, then the security context of the new connection is cryptographically tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake. In TLS 1.2 and below, this functionality was provided by "session IDs" and "session tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.
虽然可以在带外建立TLS PSK，但也可以在以前的连接中建立PSK，然后用于建立新连接（“会话恢复”或使用PSK“恢复”）。握手完成后，服务器可以向客户端发送一个PSK标识，该标识对应于从初始握手派生的唯一密钥（参见第4.6.1节）。然后，客户端可以在将来的握手中使用该PSK标识来协商相关PSK的使用。如果服务器接受PSK，则新连接的安全上下文将以加密方式绑定到原始连接，并且从初始握手派生的密钥将用于引导加密状态，而不是完全握手。在TLS 1.2及以下版本中，该功能由“会话ID”和“会话票证”[RFC5077]提供。这两种机制在TLS 1.3中都已过时。
PSKs can be used with (EC)DHE key exchange in order to provide forward secrecy in combination with shared keys, or can be used alone, at the cost of losing forward secrecy for the application data.
PSK可以与（EC）DHE密钥交换一起使用，以便与共享密钥一起提供前向保密性，或者可以单独使用，但代价是失去应用程序数据的前向保密性。
Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it:
图3显示了一对握手，其中第一次握手建立PSK，第二次握手使用PSK：
Client Server
客户端服务器
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Initial Handshake:
ClientHello
+ key_share -------->
ServerHello
+ key_share
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
{Certificate*}
{CertificateVerify*}
{Finished} -------->
<-------- [NewSessionTicket]
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Subsequent Handshake:
ClientHello
+ key_share*
+ pre_shared_key -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
{Finished}
<-------- [Application Data*]
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 3: Message Flow for Resumption and PSK
图3：恢复和PSK的消息流
As the server is authenticating via a PSK, it does not send a Certificate or a CertificateVerify message. When a client offers resumption via a PSK, it SHOULD also supply a "key_share" extension to the server to allow the server to decline resumption and fall back to a full handshake, if needed. The server responds with a "pre_shared_key" extension to negotiate the use of PSK key establishment and can (as shown here) respond with a "key_share" extension to do (EC)DHE key establishment, thus providing forward secrecy.
由于服务器正在通过PSK进行身份验证，因此它不会发送证书或CertificateVerify消息。当客户端通过PSK提供恢复时，它还应向服务器提供“密钥共享”扩展，以允许服务器拒绝恢复，并在需要时返回到完全握手。服务器使用“pre_shared_key”扩展进行响应，以协商PSK密钥建立的使用，并且可以（如图所示）使用“key_shared”扩展进行响应，从而提供前向保密性。
When PSKs are provisioned out of band, the PSK identity and the KDF hash algorithm to be used with the PSK MUST also be provisioned.
在带外提供PSK时，还必须提供PSK标识和与PSK一起使用的KDF哈希算法。
Note: When using an out-of-band provisioned pre-shared secret, a critical consideration is using sufficient entropy during the key generation, as discussed in [RFC4086]. Deriving a shared secret from a password or other low-entropy sources is not secure. A low-entropy secret, or password, is subject to dictionary attacks based on the PSK binder. The specified PSK authentication is not a strong password-based authenticated key exchange even when used with Diffie-Hellman key establishment. Specifically, it does not prevent an attacker that can observe the handshake from performing a brute-force attack on the password/pre-shared key.
注：当使用带外配置的预共享秘密时，关键考虑因素是在密钥生成期间使用足够的熵，如[RFC4086]中所述。从密码或其他低熵源获取共享秘密是不安全的。低熵秘密或密码会受到基于PSK绑定器的字典攻击。即使与Diffie-Hellman密钥建立一起使用，指定的PSK身份验证也不是基于密码的强身份验证密钥交换。特别是，它不能阻止能够观察握手的攻击者对密码/预共享密钥执行暴力攻击。
When clients and servers share a PSK (either obtained externally or via a previous handshake), TLS 1.3 allows clients to send data on the first flight ("early data"). The client uses the PSK to authenticate the server and to encrypt the early data.
当客户端和服务器共享PSK（从外部获得或通过先前的握手获得）时，TLS 1.3允许客户端在第一次航班上发送数据（“早期数据”）。客户端使用PSK对服务器进行身份验证并加密早期数据。
As shown in Figure 4, the 0-RTT data is just added to the 1-RTT handshake in the first flight. The rest of the handshake uses the same messages as for a 1-RTT handshake with PSK resumption.
如图4所示，0-RTT数据只是添加到第一次飞行中的1-RTT握手中。握手的其余部分使用与PSK恢复的1-RTT握手相同的消息。
Client Server
客户端服务器
ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*) -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
+ early_data*
{Finished}
<-------- [Application Data*]
(EndOfEarlyData)
{Finished} -------->
[Application Data] <-------> [Application Data]
ClientHello
+ early_data
+ key_share*
+ psk_key_exchange_modes
+ pre_shared_key
(Application Data*) -------->
ServerHello
+ pre_shared_key
+ key_share*
{EncryptedExtensions}
+ early_data*
{Finished}
<-------- [Application Data*]
(EndOfEarlyData)
{Finished} -------->
[Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the previously noted message.
+ 指示在先前注意到的消息中发送的值得注意的扩展。
* Indicates optional or situation-dependent messages/extensions that are not always sent.
* 指示不总是发送的可选或依赖于情况的消息/扩展。
() Indicates messages protected using keys derived from a client_early_traffic_secret.
（）表示使用从客户端\u早期\u流量\u机密派生的密钥保护的消息。
{} Indicates messages protected using keys derived from a [sender]_handshake_traffic_secret.
{}表示使用从[发送方]\u握手\u通信\u秘密派生的密钥保护的消息。
[] Indicates messages protected using keys derived from [sender]_application_traffic_secret_N.
[]表示使用从[发件人]\u应用程序\u流量\u机密\u派生的密钥保护的邮件。
Figure 4: Message Flow for a 0-RTT Handshake
图4:0-RTT握手的消息流
IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data. Specifically:
重要提示：0-RTT数据的安全属性比其他类型TLS数据的安全属性弱。明确地：
1. This data is not forward secret, as it is encrypted solely under keys derived using the offered PSK.
1. 此数据不是前向机密，因为它仅在使用提供的PSK派生的密钥下加密。
2. There are no guarantees of non-replay between connections. Protection against replay for ordinary TLS 1.3 1-RTT data is provided via the server's Random value, but 0-RTT data does not depend on the ServerHello and therefore has weaker guarantees. This is especially relevant if the data is authenticated either with TLS client authentication or inside the application protocol. The same warnings apply to any use of the early_exporter_master_secret.
2. 不保证连接之间不重播。普通TLS 1.3 1-RTT数据的重播保护通过服务器的随机值提供，但0-RTT数据不依赖于ServerHello，因此具有较弱的保证。如果使用TLS客户端身份验证或在应用程序协议内对数据进行身份验证，则这一点尤其重要。同样的警告也适用于任何使用早期导出器主机密的情况。
0-RTT data cannot be duplicated within a connection (i.e., the server will not process the same data twice for the same connection), and an attacker will not be able to make 0-RTT data appear to be 1-RTT data (because it is protected with different keys). Appendix E.5 contains a description of potential attacks, and Section 8 describes mechanisms which the server can use to limit the impact of replay.
无法在连接中复制0-RTT数据（即，服务器不会为同一连接处理同一数据两次），并且攻击者将无法使0-RTT数据显示为1-RTT数据（因为它受不同密钥的保护）。附录E.5包含对潜在攻击的描述，第8节描述了服务器可用于限制重播影响的机制。
This document deals with the formatting of data in an external representation. The following very basic and somewhat casually defined presentation syntax will be used.
本文档处理外部表示中的数据格式。将使用以下非常基本且随意定义的表示语法。
The representation of all data items is explicitly specified. The basic data block size is one byte (i.e., 8 bits). Multiple-byte data items are concatenations of bytes, from left to right, from top to bottom. From the byte stream, a multi-byte item (a numeric in the following example) is formed (using C notation) by:
明确指定了所有数据项的表示形式。基本数据块大小为一个字节（即8位）。多字节数据项是从左到右、从上到下的字节串联。从字节流中，通过以下方式（使用C表示法）形成多字节项（下例中为数字）：
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
... | byte[n-1];
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
... | byte[n-1];
This byte ordering for multi-byte values is the commonplace network byte order or big-endian format.
多字节值的字节顺序是常见的网络字节顺序或big-endian格式。
Comments begin with "/*" and end with "*/".
注释以“/*”开头，以“*/”结尾。
Optional components are denoted by enclosing them in "[[ ]]" (double brackets).
可选组件用“[]]”（双括号）表示。
Single-byte entities containing uninterpreted data are of type opaque.
包含未解释数据的单字节实体属于不透明类型。
A type alias T' for an existing type T is defined by:
现有类型T的类型别名T'定义如下：
T T';
T′；
The basic numeric data type is an unsigned byte (uint8). All larger numeric data types are constructed from a fixed-length series of bytes concatenated as described in Section 3.1 and are also unsigned. The following numeric types are predefined.
基本数字数据类型是无符号字节（uint8）。所有较大的数值数据类型都是由固定长度的字节序列构成的，如第3.1节所述，这些字节串接在一起，并且也是无符号的。以下数字类型是预定义的。
uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];
uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];
All values, here and elsewhere in the specification, are transmitted in network byte (big-endian) order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060.
规范中此处和其他地方的所有值均以网络字节（大端）顺序传输；十六进制字节01 02 03 04表示的uint32相当于十进制值16909060。
A vector (single-dimensioned array) is a stream of homogeneous data elements. The size of the vector may be specified at documentation time or left unspecified until runtime. In either case, the length declares the number of bytes, not the number of elements, in the vector. The syntax for specifying a new type, T', that is a fixed-length vector of type T is
向量（一维数组）是同质数据元素的流。向量的大小可以在文档编制时指定，也可以在运行时才指定。在任何一种情况下，长度都声明向量中的字节数，而不是元素数。指定新类型T'的语法为
T T'[n];
T′[n]；
Here, T' occupies n bytes in the data stream, where n is a multiple of the size of T. The length of the vector is not included in the encoded stream.
这里，T'在数据流中占据n个字节，其中n是T的大小的倍数。矢量的长度不包括在编码流中。
In the following example, Datum is defined to be three consecutive bytes that the protocol does not interpret, while Data is three consecutive Datum, consuming a total of nine bytes.
在下面的示例中，数据被定义为协议不解释的三个连续字节，而数据是三个连续的数据，总共消耗九个字节。
opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* three consecutive 3-byte vectors */
opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* three consecutive 3-byte vectors */
Variable-length vectors are defined by specifying a subrange of legal lengths, inclusively, using the notation <floor..ceiling>. When these are encoded, the actual length precedes the vector's contents in the byte stream. The length will be in the form of a number consuming as many bytes as required to hold the vector's specified maximum (ceiling) length. A variable-length vector with an actual length field of zero is referred to as an empty vector.
可变长度向量是通过指定合法长度的子范围来定义的，包括使用符号<floor..天花>。当对这些内容进行编码时，实际长度先于字节流中向量的内容。长度将以一个数字的形式出现，该数字消耗的字节数与保持向量指定的最大（上限）长度所需的字节数相同。实际长度字段为零的可变长度向量称为空向量。
T T'<floor..ceiling>;
T T'<floor..ceiling>;
In the following example, "mandatory" is a vector that must contain between 300 and 400 bytes of type opaque. It can never be empty. The actual length field consumes two bytes, a uint16, which is sufficient to represent the value 400 (see Section 3.3). Similarly, "longer" can represent up to 800 bytes of data, or 400 uint16 elements, and it may be empty. Its encoding will include a two-byte actual length field prepended to the vector. The length of an encoded vector must be an exact multiple of the length of a single element (e.g., a 17-byte vector of uint16 would be illegal).
在下面的示例中，“强制”是一个必须包含300到400字节类型不透明的向量。它永远不会是空的。实际长度字段消耗两个字节，一个uint16，足以表示值400（参见第3.3节）。类似地，“longer”可以表示多达800字节的数据，或400个uint16元素，并且可以是空的。它的编码将包括一个在向量前面的两字节实际长度字段。编码向量的长度必须是单个元素长度的精确倍数（例如，uint16的17字节向量是非法的）。
opaque mandatory<300..400>;
/* length field is two bytes, cannot be empty */
uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */
opaque mandatory<300..400>;
/* length field is two bytes, cannot be empty */
uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */
An additional sparse data type, called "enum" or "enumerated", is available. Each definition is a different type. Only enumerateds of the same type may be assigned or compared. Every element of an enumerated must be assigned a value, as demonstrated in the following example. Since the elements of the enumerated are not ordered, they can be assigned any unique value, in any order.
另外还有一种稀疏数据类型，称为“枚举”或“枚举”。每个定义都是不同的类型。只能分配或比较相同类型的枚举。枚举的每个元素都必须分配一个值，如下例所示。由于枚举的元素没有顺序，因此可以按任何顺序为它们分配任何唯一的值。
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
Future extensions or additions to the protocol may define new values. Implementations need to be able to parse and ignore unknown values unless the definition of the field states otherwise.
未来对协议的扩展或添加可能会定义新的值。实现需要能够解析和忽略未知值，除非字段的定义另有说明。
An enumerated occupies as much space in the byte stream as would its maximal defined ordinal value. The following definition would cause one byte to be used to carry fields of type Color.
枚举数组在字节流中所占的空间与其定义的最大序数值相同。以下定义将导致使用一个字节来携带Color类型的字段。
enum { red(3), blue(5), white(7) } Color;
enum { red(3), blue(5), white(7) } Color;
One may optionally specify a value without its associated tag to force the width definition without defining a superfluous element.
可以选择指定一个没有关联标记的值，以强制进行宽度定义，而不定义多余的元素。
In the following example, Taste will consume two bytes in the data stream but can only assume the values 1, 2, or 4 in the current version of the protocol.
在下面的示例中，Taste将在数据流中消耗两个字节，但在协议的当前版本中只能假定值1、2或4。
enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
The names of the elements of an enumeration are scoped within the defined type. In the first example, a fully qualified reference to the second element of the enumeration would be Color.blue. Such qualification is not required if the target of the assignment is well specified.
枚举元素的名称在定义的类型范围内。在第一个示例中，枚举的第二个元素的完全限定引用是Color.blue。如果明确规定了任务目标，则不需要此类资格。
Color color = Color.blue; /* overspecified, legal */
Color color = blue; /* correct, type implicit */
Color color = Color.blue; /* overspecified, legal */
Color color = blue; /* correct, type implicit */
The names assigned to enumerateds do not need to be unique. The numerical value can describe a range over which the same name applies. The value includes the minimum and maximum inclusive values in that range, separated by two period characters. This is principally useful for reserving regions of the space.
分配给枚举的名称不需要是唯一的。数值可以描述应用相同名称的范围。该值包括该范围内的最小和最大包含值，由两个句点字符分隔。这主要用于保留空间区域。
enum { sad(0), meh(1..254), happy(255) } Mood;
enum { sad(0), meh(1..254), happy(255) } Mood;
Structure types may be constructed from primitive types for convenience. Each specification declares a new, unique type. The syntax used for definitions is much like that of C.
为方便起见，可以从基元类型构造结构类型。每个规范都声明了一个新的、唯一的类型。用于定义的语法与C非常相似。
struct {
T1 f1;
T2 f2;
...
Tn fn;
} T;
struct {
T1 f1;
T2 f2;
...
Tn fn;
} T;
Fixed- and variable-length vector fields are allowed using the standard vector syntax. Structures V1 and V2 in the variants example (Section 3.8) demonstrate this.
允许使用标准向量语法使用固定长度和可变长度向量字段。变体示例（第3.8节）中的结构V1和V2证明了这一点。
The fields within a structure may be qualified using the type's name, with a syntax much like that available for enumerateds. For example, T.f2 refers to the second field of the previous declaration.
结构中的字段可以使用类型的名称进行限定，其语法非常类似于枚举。例如，T.f2引用上一个声明的第二个字段。
Fields and variables may be assigned a fixed value using "=", as in:
可以使用“=”为字段和变量指定一个固定值，如下所示：
struct {
T1 f1 = 8; /* T.f1 must always be 8 */
T2 f2;
} T;
struct {
T1 f1 = 8; /* T.f1 must always be 8 */
T2 f2;
} T;
Defined structures may have variants based on some knowledge that is available within the environment. The selector must be an enumerated type that defines the possible variants the structure defines. Each arm of the select (below) specifies the type of that variant's field and an optional field label. The mechanism by which the variant is selected at runtime is not prescribed by the presentation language.
定义的结构可能具有基于环境中可用的某些知识的变体。选择器必须是定义结构定义的可能变量的枚举类型。select（下面）的每个臂指定该变量字段的类型和可选字段标签。表示语言没有规定在运行时选择变体的机制。
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1 [[fe1]];
case e2: Te2 [[fe2]];
....
case en: Ten [[fen]];
};
} Tv;
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1 [[fe1]];
case e2: Te2 [[fe2]];
....
case en: Ten [[fen]];
};
} Tv;
For example:
例如：
enum { apple(0), orange(1) } VariantTag;
enum { apple(0), orange(1) } VariantTag;
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;
struct {
uint32 number;
opaque string[10]; /* fixed length */
} V2;
struct {
uint32 number;
opaque string[10]; /* fixed length */
} V2;
struct {
VariantTag type;
select (VariantRecord.type) {
case apple: V1;
case orange: V2;
};
} VariantRecord;
struct {
VariantTag type;
select (VariantRecord.type) {
case apple: V1;
case orange: V2;
};
} VariantRecord;
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.
握手协议用于协商连接的安全参数。握手消息被提供给TLS记录层，在TLS记录层中，它们被封装在一个或多个TLSPlaintext或TLSCiphertext结构中，这些结构按照当前活动连接状态的规定进行处理和传输。
enum {
client_hello(1),
server_hello(2),
new_session_ticket(4),
end_of_early_data(5),
encrypted_extensions(8),
certificate(11),
certificate_request(13),
certificate_verify(15),
finished(20),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
enum {
client_hello(1),
server_hello(2),
new_session_ticket(4),
end_of_early_data(5),
encrypted_extensions(8),
certificate(11),
certificate_request(13),
certificate_verify(15),
finished(20),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* remaining bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* remaining bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;
Protocol messages MUST be sent in the order defined in Section 4.4.1 and shown in the diagrams in Section 2. A peer which receives a handshake message in an unexpected order MUST abort the handshake with an "unexpected_message" alert.
协议消息必须按照第4.4.1节规定的顺序发送，并在第2节的图表中显示。以意外顺序接收握手消息的对等方必须使用“意外消息”警报中止握手。
New handshake message types are assigned by IANA as described in Section 11.
新的握手消息类型由IANA分配，如第11节所述。
The key exchange messages are used to determine the security capabilities of the client and the server and to establish shared secrets, including the traffic keys used to protect the rest of the handshake and the data.
密钥交换消息用于确定客户端和服务器的安全能力，并建立共享机密，包括用于保护其余握手和数据的通信密钥。
In TLS, the cryptographic negotiation proceeds by the client offering the following four sets of options in its ClientHello:
在TLS中，加密协商由客户端在其ClientHello中提供以下四组选项进行：
- A list of cipher suites which indicates the AEAD algorithm/HKDF hash pairs which the client supports.
- 密码套件列表，指示客户端支持的AEAD算法/HKDF哈希对。
- A "supported_groups" (Section 4.2.7) extension which indicates the (EC)DHE groups which the client supports and a "key_share" (Section 4.2.8) extension which contains (EC)DHE shares for some or all of these groups.
- “受支持的_组”（第4.2.7节）扩展，表示客户支持的（EC）DHE组，以及“密钥共享”（第4.2.8节）扩展，其中包含部分或所有这些组的（EC）DHE共享。
- A "signature_algorithms" (Section 4.2.3) extension which indicates the signature algorithms which the client can accept. A "signature_algorithms_cert" extension (Section 4.2.3) may also be added to indicate certificate-specific signature algorithms.
- “签名算法”（第4.2.3节）扩展，表示客户可以接受的签名算法。还可以添加“签名算法证书”扩展（第4.2.3节），以指示特定于证书的签名算法。
- A "pre_shared_key" (Section 4.2.11) extension which contains a list of symmetric key identities known to the client and a "psk_key_exchange_modes" (Section 4.2.9) extension which indicates the key exchange modes that may be used with PSKs.
- “预共享密钥”（第4.2.11节）扩展，包含客户端已知的对称密钥标识列表，以及“psk密钥交换模式”（第4.2.9节）扩展，指示可与psk一起使用的密钥交换模式。
If the server does not select a PSK, then the first three of these options are entirely orthogonal: the server independently selects a cipher suite, an (EC)DHE group and key share for key establishment, and a signature algorithm/certificate pair to authenticate itself to the client. If there is no overlap between the received "supported_groups" and the groups supported by the server, then the server MUST abort the handshake with a "handshake_failure" or an "insufficient_security" alert.
如果服务器没有选择PSK，那么前三个选项是完全正交的：服务器独立选择密码套件、用于密钥建立的（EC）DHE组和密钥共享，以及用于向客户端验证自身的签名算法/证书对。如果收到的“支持的组”与服务器支持的组之间没有重叠，则服务器必须通过“握手失败”或“安全性不足”警报中止握手。
If the server selects a PSK, then it MUST also select a key establishment mode from the set indicated by the client's "psk_key_exchange_modes" extension (at present, PSK alone or with (EC)DHE). Note that if the PSK can be used without (EC)DHE, then non-overlap in the "supported_groups" parameters need not be fatal, as it is in the non-PSK case discussed in the previous paragraph.
如果服务器选择了PSK，那么它还必须从客户端的“PSK密钥交换模式”扩展（目前，PSK单独或与（EC）DHE一起）所指示的集合中选择密钥建立模式。请注意，如果PSK可以在没有（EC）DHE的情况下使用，那么“受支持的_组”参数中的不重叠不一定是致命的，正如前一段中讨论的非PSK情况一样。
If the server selects an (EC)DHE group and the client did not offer a compatible "key_share" extension in the initial ClientHello, the server MUST respond with a HelloRetryRequest (Section 4.1.4) message.
如果服务器选择（EC）DHE组，而客户端在初始客户端中未提供兼容的“密钥共享”扩展，则服务器必须以HelloRetryRequest（第4.1.4节）消息响应。
If the server successfully selects parameters and does not require a HelloRetryRequest, it indicates the selected parameters in the ServerHello as follows:
如果服务器成功选择参数并且不需要HelloRetryRequest，则会在ServerHello中指示所选参数，如下所示：
- If PSK is being used, then the server will send a "pre_shared_key" extension indicating the selected key.
- 如果正在使用PSK，则服务器将发送一个“pre_shared_key”扩展名，指示所选密钥。
- When (EC)DHE is in use, the server will also provide a "key_share" extension. If PSK is not being used, then (EC)DHE and certificate-based authentication are always used.
- 使用（EC）DHE时，服务器还将提供“密钥共享”扩展。如果未使用PSK，则始终使用（EC）DHE和基于证书的身份验证。
- When authenticating via a certificate, the server will send the Certificate (Section 4.4.2) and CertificateVerify (Section 4.4.3) messages. In TLS 1.3 as defined by this document, either a PSK or a certificate is always used, but not both. Future documents may define how to use them together.
- 通过证书进行身份验证时，服务器将发送证书（第4.4.2节）和CertificateVerify（第4.4.3节）消息。在本文件定义的TLS 1.3中，始终使用PSK或证书，但不能同时使用两者。未来的文档可能会定义如何将它们一起使用。
If the server is unable to negotiate a supported set of parameters (i.e., there is no overlap between the client and server parameters), it MUST abort the handshake with either a "handshake_failure" or "insufficient_security" fatal alert (see Section 6).
如果服务器无法协商一组受支持的参数（即，客户端和服务器参数之间没有重叠），则必须通过“握手失败”或“安全性不足”致命警报中止握手（参见第6节）。
When a client first connects to a server, it is REQUIRED to send the ClientHello as its first TLS message. The client will also send a ClientHello when the server has responded to its ClientHello with a HelloRetryRequest. In that case, the client MUST send the same ClientHello without modification, except as follows:
当客户机第一次连接到服务器时，需要将ClientHello作为其第一条TLS消息发送。当服务器用HelloRetryRequest响应其ClientHello时，客户端还将发送ClientHello。在这种情况下，客户端必须发送相同的ClientHello而不进行修改，以下情况除外：
- If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group.
- 如果HelloRetryRequest中提供了“密钥共享”扩展名，则将共享列表替换为包含来自指定组的单个密钥共享的列表。
- Removing the "early_data" extension (Section 4.2.10) if one was present. Early data is not permitted after a HelloRetryRequest.
- 如果存在“早期数据”扩展（第4.2.10节），则删除该扩展。HelloRetryRequest后不允许使用早期数据。
- Including a "cookie" extension if one was provided in the HelloRetryRequest.
- 如果HelloRetryRequest中提供了“cookie”扩展，则包括该扩展。
- Updating the "pre_shared_key" extension if present by recomputing the "obfuscated_ticket_age" and binder values and (optionally) removing any PSKs which are incompatible with the server's indicated cipher suite.
- 更新“预共享密钥”扩展名（如果存在），方法是重新计算“模糊化密钥”和绑定值，并（可选）删除与服务器指定密码套件不兼容的任何PSK。
- Optionally adding, removing, or changing the length of the "padding" extension [RFC7685].
- 可选地添加、删除或更改“填充”扩展的长度[RFC7685]。
- Other modifications that may be allowed by an extension defined in the future and present in the HelloRetryRequest.
- 将来定义的扩展可能允许的其他修改，并在HelloRetryRequest中出现。
Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS 1.3 and receives a ClientHello at any other time, it MUST terminate the connection with an "unexpected_message" alert.
由于TLS 1.3禁止重新协商，如果服务器已协商TLS 1.3并在任何其他时间收到ClientHello，则必须使用“意外消息”警报终止连接。
If a server established a TLS connection with a previous version of TLS and receives a TLS 1.3 ClientHello in a renegotiation, it MUST retain the previous protocol version. In particular, it MUST NOT negotiate TLS 1.3.
如果服务器与以前版本的TLS建立了TLS连接，并在重新协商中收到TLS 1.3 ClientHello，则必须保留以前的协议版本。特别是，不得协商TLS 1.3。
Structure of this message:
此消息的结构：
uint16 ProtocolVersion;
opaque Random[32];
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
legacy_version: In previous versions of TLS, this field was used for version negotiation and represented the highest version number supported by the client. Experience has shown that many servers do not properly implement version negotiation, leading to "version intolerance" in which the server rejects an otherwise acceptable ClientHello with a version number higher than it supports. In TLS 1.3, the client indicates its version preferences in the "supported_versions" extension (Section 4.2.1) and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. TLS 1.3 ClientHellos are identified as having a legacy_version of 0x0303 and a supported_versions extension present with 0x0304 as the highest version indicated therein. (See Appendix D for details about backward compatibility.)
遗留版本：在TLS的早期版本中，此字段用于版本协商，表示客户端支持的最高版本号。经验表明，许多服务器没有正确实施版本协商，导致“版本不容忍”，即服务器拒绝版本号高于其支持的其他可接受的ClientHello。在TLS 1.3中，客户端在“受支持的_版本”扩展（第4.2.1节）中指示其版本首选项，并且旧版_版本字段必须设置为0x0303，这是TLS 1.2的版本号。TLS 1.3 ClientHello被标识为具有0x0303的旧版_版本和支持的_版本扩展，其中0x0304是其中指示的最高版本。（有关向后兼容性的详细信息，请参见附录D。）
random: 32 bytes generated by a secure random number generator. See Appendix C for additional information.
随机：由安全随机数生成器生成的32字节。更多信息见附录C。
legacy_session_id: Versions of TLS before TLS 1.3 supported a "session resumption" feature which has been merged with pre-shared keys in this version (see Section 2.2). A client which has a cached session ID set by a pre-TLS 1.3 server SHOULD set this field to that value. In compatibility mode (see Appendix D.4), this field MUST be non-empty, so a client not offering a pre-TLS 1.3 session MUST generate a new 32-byte value. This value need not be random but SHOULD be unpredictable to avoid implementations fixating on a specific value (also known as ossification). Otherwise, it MUST be set as a zero-length vector (i.e., a zero-valued single byte length field).
遗留会话id:TLS 1.3之前的TLS版本支持“会话恢复”功能，该功能已与该版本中的预共享密钥合并（参见第2.2节）。具有由TLS 1.3之前的服务器设置的缓存会话ID的客户端应将此字段设置为该值。在兼容模式下（见附录D.4），此字段必须为非空，因此不提供TLS 1.3之前会话的客户端必须生成新的32字节值。这个值不需要是随机的，但应该是不可预测的，以避免实现固定在特定的值上（也称为僵化）。否则，必须将其设置为零长度向量（即，零值单字节长度字段）。
cipher_suites: A list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including secret key length) and a hash to be used with HKDF, in descending order of client preference. Values are defined in Appendix B.4. If the list contains cipher suites that the server does not recognize, support, or wish to use, the server MUST ignore those cipher suites and process the remaining ones as usual. If the client is attempting a PSK key establishment, it SHOULD advertise at least one cipher suite indicating a Hash associated with the PSK.
cipher_suites：客户端支持的对称密码选项列表，特别是记录保护算法（包括密钥长度）和与HKDF一起使用的哈希，按客户端首选项的降序排列。数值在附录B.4中定义。如果列表包含服务器不识别、不支持或不希望使用的密码套件，则服务器必须忽略这些密码套件，并像往常一样处理其余的密码套件。如果客户机正在尝试建立PSK密钥，它应该公布至少一个密码套件，指示与PSK关联的哈希。
legacy_compression_methods: Versions of TLS before 1.3 supported compression with the list of supported compression methods being sent in this field. For every TLS 1.3 ClientHello, this vector MUST contain exactly one byte, set to zero, which corresponds to the "null" compression method in prior versions of TLS. If a TLS 1.3 ClientHello is received with any other value in this field, the server MUST abort the handshake with an "illegal_parameter" alert. Note that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which contain other compression methods and (if negotiating such a prior version) MUST follow the procedures for the appropriate prior version of TLS.
传统压缩方法：1.3版本之前的TLS支持压缩，支持的压缩方法列表在此字段中发送。对于每个TLS 1.3 ClientHello，该向量必须正好包含一个字节，设置为零，这与TLS早期版本中的“null”压缩方法相对应。如果接收到TLS 1.3 ClientHello以及此字段中的任何其他值，服务器必须使用“非法参数”警报中止握手。请注意，TLS 1.3服务器可能会接收包含其他压缩方法的TLS 1.2或以前版本的ClientHello，并且（如果协商此类以前版本），必须遵循TLS相应以前版本的程序。
extensions: Clients request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 4.2. In TLS 1.3, the use of certain extensions is mandatory, as functionality has moved into extensions to preserve ClientHello compatibility with previous versions of TLS. Servers MUST ignore unrecognized extensions.
扩展：客户端通过在扩展字段中发送数据，从服务器请求扩展功能。第4.2节定义了实际的“扩展”格式。在TLS1.3中，某些扩展的使用是强制性的，因为功能已经转移到扩展中，以保持ClientHello与TLS以前版本的兼容性。服务器必须忽略无法识别的扩展。
All versions of TLS allow an extensions field to optionally follow the compression_methods field. TLS 1.3 ClientHello messages always contain extensions (minimally "supported_versions", otherwise, they will be interpreted as TLS 1.2 ClientHello messages). However, TLS 1.3 servers might receive ClientHello messages without an extensions field from prior versions of TLS. The presence of extensions can be detected by determining whether there are bytes following the compression_methods field at the end of the ClientHello. Note that this method of detecting optional data differs from the normal TLS method of having a variable-length field, but it is used for compatibility with TLS before extensions were defined. TLS 1.3 servers will need to perform this check first and only attempt to negotiate TLS 1.3 if the "supported_versions" extension is present. If negotiating a version of TLS prior to 1.3, a server MUST check that the message either contains no data after legacy_compression_methods or that it contains a valid extensions block with no data following. If not, then it MUST abort the handshake with a "decode_error" alert.
TLS的所有版本都允许扩展字段可选地遵循压缩方法字段。TLS 1.3 ClientHello消息始终包含扩展（最低限度为“受支持的_版本”，否则，它们将被解释为TLS 1.2 ClientHello消息）。但是，TLS 1.3服务器可能会从以前版本的TLS接收不带扩展字段的ClientHello消息。通过确定ClientHello末尾的compression_methods字段后面是否有字节，可以检测是否存在扩展。请注意，这种检测可选数据的方法不同于具有可变长度字段的常规TLS方法，但它用于在定义扩展之前与TLS兼容。TLS 1.3服务器需要首先执行此检查，并且只有在存在“受支持的_版本”扩展时才尝试协商TLS 1.3。如果协商1.3之前版本的TLS，服务器必须检查消息是否在旧的\u压缩\u方法之后不包含任何数据，或者它是否包含有效的扩展块，后面没有数据。如果没有，则必须通过“解码错误”警报中止握手。
In the event that a client requests additional functionality using extensions and this functionality is not supplied by the server, the client MAY abort the handshake.
如果客户端使用扩展请求附加功能，而服务器未提供此功能，则客户端可能会中止握手。
After sending the ClientHello message, the client waits for a ServerHello or HelloRetryRequest message. If early data is in use, the client may transmit early Application Data (Section 2.3) while waiting for the next handshake message.
发送ClientHello消息后，客户端等待ServerHello或HelloRetryRequest消息。如果正在使用早期数据，则客户端可以在等待下一个握手消息时传输早期应用程序数据（第2.3节）。
The server will send this message in response to a ClientHello message to proceed with the handshake if it is able to negotiate an acceptable set of handshake parameters based on the ClientHello.
如果服务器能够根据ClientHello协商一组可接受的握手参数，则服务器将发送此消息作为对ClientHello消息的响应，以继续握手。
Structure of this message:
此消息的结构：
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello;
legacy_version: In previous versions of TLS, this field was used for version negotiation and represented the selected version number for the connection. Unfortunately, some middleboxes fail when presented with new values. In TLS 1.3, the TLS server indicates its version using the "supported_versions" extension (Section 4.2.1), and the legacy_version field MUST be set to 0x0303, which is the version number for TLS 1.2. (See Appendix D for details about backward compatibility.)
旧版本：在TLS的早期版本中，此字段用于版本协商，并表示为连接选择的版本号。不幸的是，一些中间盒在出现新值时失败。在TLS 1.3中，TLS服务器使用“受支持的_版本”扩展（第4.2.1节）指示其版本，并且旧版_版本字段必须设置为0x0303，这是TLS 1.2的版本号。（有关向后兼容性的详细信息，请参见附录D。）
random: 32 bytes generated by a secure random number generator. See Appendix C for additional information. The last 8 bytes MUST be overwritten as described below if negotiating TLS 1.2 or TLS 1.1, but the remaining bytes MUST be random. This structure is generated by the server and MUST be generated independently of the ClientHello.random.
随机：由安全随机数生成器生成的32字节。更多信息见附录C。如果协商TLS 1.2或TLS 1.1，则必须按如下所述覆盖最后8个字节，但剩余字节必须是随机的。此结构由服务器生成，必须独立于ClientHello.random生成。
legacy_session_id_echo: The contents of the client's legacy_session_id field. Note that this field is echoed even if the client's value corresponded to a cached pre-TLS 1.3 session which the server has chosen not to resume. A client which receives a legacy_session_id_echo field that does not match what it sent in the ClientHello MUST abort the handshake with an "illegal_parameter" alert.
legacy_session_id_echo：客户端legacy_session_id字段的内容。请注意，即使客户端的值与服务器选择不恢复的缓存的TLS 1.3之前的会话相对应，也会回显此字段。如果客户端接收到与客户端中发送的内容不匹配的旧\u会话\u id\u echo字段，则必须使用“非法\u参数”警报中止握手。
cipher_suite: The single cipher suite selected by the server from the list in ClientHello.cipher_suites. A client which receives a cipher suite that was not offered MUST abort the handshake with an "illegal_parameter" alert.
cipher_套件：服务器从ClientHello.cipher_套件中的列表中选择的单个密码套件。接收到未提供的密码套件的客户端必须使用“非法参数”警报中止握手。
legacy_compression_method: A single byte which MUST have the value 0.
传统压缩方法：一个单字节，其值必须为0。
extensions: A list of extensions. The ServerHello MUST only include extensions which are required to establish the cryptographic context and negotiate the protocol version. All TLS 1.3 ServerHello messages MUST contain the "supported_versions" extension. Current ServerHello messages additionally contain either the "pre_shared_key" extension or the "key_share" extension, or both (when using a PSK with (EC)DHE key establishment). Other extensions (see Section 4.2) are sent separately in the EncryptedExtensions message.
扩展：扩展的列表。ServerHello必须只包含建立加密上下文和协商协议版本所需的扩展。所有TLS 1.3 ServerHello消息必须包含“受支持的\u版本”扩展名。当前ServerHello消息还包含“pre_shared_key”扩展名或“key_share”扩展名，或同时包含这两个扩展名（当使用带有（EC）DHE密钥建立的PSK时）。其他扩展（见第4.2节）在EncryptedExtensions消息中单独发送。
For reasons of backward compatibility with middleboxes (see Appendix D.4), the HelloRetryRequest message uses the same structure as the ServerHello, but with Random set to the special value of the SHA-256 of "HelloRetryRequest":
出于与中间盒向后兼容的原因（参见附录D.4），HelloRetryRequest消息使用与ServerHello相同的结构，但随机设置为“HelloRetryRequest”的SHA-256的特殊值：
CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C
CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91 C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C
Upon receiving a message with type server_hello, implementations MUST first examine the Random value and, if it matches this value, process it as described in Section 4.1.4).
在收到类型为server_hello的消息后，实现必须首先检查随机值，如果它与此值匹配，则按照第4.1.4节所述进行处理。
TLS 1.3 has a downgrade protection mechanism embedded in the server's random value. TLS 1.3 servers which negotiate TLS 1.2 or below in response to a ClientHello MUST set the last 8 bytes of their Random value specially in their ServerHello.
TLS 1.3在服务器的随机值中嵌入了降级保护机制。协商TLS 1.2或更低版本以响应ClientHello的TLS 1.3服务器必须特别在其ServerHello中设置其随机值的最后8个字节。
If negotiating TLS 1.2, TLS 1.3 servers MUST set the last 8 bytes of their Random value to the bytes:
如果协商TLS 1.2，TLS 1.3服务器必须将其随机值的最后8个字节设置为：
44 4F 57 4E 47 52 44 01
44 4F 57 4E 47 52 44 01
If negotiating TLS 1.1 or below, TLS 1.3 servers MUST, and TLS 1.2 servers SHOULD, set the last 8 bytes of their ServerHello.Random value to the bytes:
如果协商TLS 1.1或更低版本，TLS 1.3服务器必须，TLS 1.2服务器应设置其服务器Hello的最后8个字节。将随机值设置为字节：
44 4F 57 4E 47 52 44 00
44 4F 57 4E 47 52 44 00
TLS 1.3 clients receiving a ServerHello indicating TLS 1.2 or below MUST check that the last 8 bytes are not equal to either of these values. TLS 1.2 clients SHOULD also check that the last 8 bytes are not equal to the second value if the ServerHello indicates TLS 1.1 or below. If a match is found, the client MUST abort the handshake with an "illegal_parameter" alert. This mechanism provides limited protection against downgrade attacks over and above what is provided by the Finished exchange: because the ServerKeyExchange, a message present in TLS 1.2 and below, includes a signature over both random values, it is not possible for an active attacker to modify the
接收指示TLS 1.2或更低版本的ServerHello的TLS 1.3客户端必须检查最后8个字节是否不等于这些值。如果ServerHello指示TLS 1.1或更低，则TLS 1.2客户端还应检查最后8个字节是否不等于第二个值。如果找到匹配项，客户端必须使用“非法参数”警报中止握手。此机制提供了有限的保护，以防止在完成的exchange上发生降级攻击：因为ServerKeyExchange（TLS 1.2及以下版本中的消息）包含两个随机值上的签名，所以活动攻击者不可能修改
random values without detection as long as ephemeral ciphers are used. It does not provide downgrade protection when static RSA is used.
只要使用临时密码，就不需要检测随机值。当使用静态RSA时，它不提供降级保护。
Note: This is a change from [RFC5246], so in practice many TLS 1.2 clients and servers will not behave as specified above.
注意：这是对[RFC5246]的更改，因此在实践中，许多TLS 1.2客户端和服务器的行为将不符合上述规定。
A legacy TLS client performing renegotiation with TLS 1.2 or prior and which receives a TLS 1.3 ServerHello during renegotiation MUST abort the handshake with a "protocol_version" alert. Note that renegotiation is not possible when TLS 1.3 has been negotiated.
与TLS 1.2或更早版本进行重新协商并在重新协商期间收到TLS 1.3 ServerHello的传统TLS客户端必须使用“协议版本”警报中止握手。请注意，当TLS 1.3已协商时，不可能重新协商。
The server will send this message in response to a ClientHello message if it is able to find an acceptable set of parameters but the ClientHello does not contain sufficient information to proceed with the handshake. As discussed in Section 4.1.3, the HelloRetryRequest has the same format as a ServerHello message, and the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method fields have the same meaning. However, for convenience we discuss "HelloRetryRequest" throughout this document as if it were a distinct message.
如果服务器能够找到一组可接受的参数，但ClientHello中没有足够的信息继续握手，则服务器将发送此消息以响应ClientHello消息。如第4.1.3节所述，HelloRetryRequest与ServerHello消息具有相同的格式，而legacy_版本、legacy_会话_id_echo、cipher_套件和legacy_压缩_方法字段具有相同的含义。然而，为了方便起见，我们在整个文档中讨论“HelloRetryRequest”，就好像它是一条独特的消息一样。
The server's extensions MUST contain "supported_versions". Additionally, it SHOULD contain the minimal set of extensions necessary for the client to generate a correct ClientHello pair. As with the ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello, with the exception of optionally the "cookie" (see Section 4.2.2) extension.
服务器的扩展必须包含“受支持的\u版本”。此外，它应该包含客户端生成正确的ClientHello对所需的最小扩展集。与ServerHello一样，HelloRetryRequest不能包含任何不是客户机在其ClientHello中首先提供的扩展，可选的“cookie”（参见第4.2.2节）扩展除外。
Upon receipt of a HelloRetryRequest, the client MUST check the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method as specified in Section 4.1.3 and then process the extensions, starting with determining the version using "supported_versions". Clients MUST abort the handshake with an "illegal_parameter" alert if the HelloRetryRequest would not result in any change in the ClientHello. If a client receives a second HelloRetryRequest in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest), it MUST abort the handshake with an "unexpected_message" alert.
在收到HelloRetryRequest后，客户端必须按照第4.1.3节的规定检查旧版\u版本、旧版\u会话\u id\u echo、密码\u套件和旧版\u压缩\u方法，然后处理扩展，首先使用“支持的\u版本”确定版本。如果HelloRetryRequest不会导致ClientHello中的任何更改，则客户端必须使用“非法_参数”警报中止握手。如果客户端在同一连接中接收到第二个HelloRetryRequest（即，ClientHello本身响应HelloRetryRequest），则必须使用“意外消息”警报中止握手。
Otherwise, the client MUST process all extensions in the HelloRetryRequest and send a second updated ClientHello. The HelloRetryRequest extensions defined in this specification are:
否则，客户端必须处理HelloRetryRequest中的所有扩展，并发送第二个更新的ClientHello。本规范中定义的HelloRetryRequest扩展包括：
- supported_versions (see Section 4.2.1)
- 支持的_版本（见第4.2.1节）
- cookie (see Section 4.2.2)
- cookie（见第4.2.2节）
- key_share (see Section 4.2.8)
- 密钥共享（见第4.2.8节）
A client which receives a cipher suite that was not offered MUST abort the handshake. Servers MUST ensure that they negotiate the same cipher suite when receiving a conformant updated ClientHello (if the server selects the cipher suite as the first step in the negotiation, then this will happen automatically). Upon receiving the ServerHello, clients MUST check that the cipher suite supplied in the ServerHello is the same as that in the HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert.
接收到未提供的密码套件的客户端必须中止握手。服务器必须确保在接收一致更新的ClientHello时协商相同的密码套件（如果服务器选择密码套件作为协商的第一步，那么这将自动发生）。在收到ServerHello后，客户端必须检查ServerHello中提供的密码套件是否与HelloRetryRequest中的密码套件相同，否则将使用“非法参数”警报中止握手。
In addition, in its updated ClientHello, the client SHOULD NOT offer any pre-shared keys associated with a hash other than that of the selected cipher suite. This allows the client to avoid having to compute partial hash transcripts for multiple hashes in the second ClientHello.
此外，在其更新的ClientHello中，客户端不应提供与哈希相关联的任何预共享密钥，所选密码套件的密钥除外。这允许客户端避免在第二个ClientHello中计算多个哈希的部分哈希转录本。
The value of selected_version in the HelloRetryRequest "supported_versions" extension MUST be retained in the ServerHello, and a client MUST abort the handshake with an "illegal_parameter" alert if the value changes.
HelloRetryRequest“supported_versions”扩展中所选_version的值必须保留在ServerHello中，如果值更改，客户端必须使用“非法_参数”警报中止握手。
A number of TLS messages contain tag-length-value encoded extensions structures.
许多TLS消息包含标记长度值编码的扩展结构。
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
Here:
在这里：
- "extension_type" identifies the particular extension type.
- “扩展类型”标识特定的扩展类型。
- "extension_data" contains information specific to the particular extension type.
- “扩展数据”包含特定于特定扩展类型的信息。
The list of extension types is maintained by IANA as described in Section 11.
扩展类型列表由IANA维护，如第11节所述。
Extensions are generally structured in a request/response fashion, though some extensions are just indications with no corresponding response. The client sends its extension requests in the ClientHello message, and the server sends its extension responses in the ServerHello, EncryptedExtensions, HelloRetryRequest, and Certificate messages. The server sends extension requests in the CertificateRequest message which a client MAY respond to with a Certificate message. The server MAY also send unsolicited extensions in the NewSessionTicket, though the client does not respond directly to these.
扩展通常以请求/响应的方式构造，尽管有些扩展只是没有相应响应的指示。客户端在ClientHello消息中发送扩展请求，服务器在ServerHello、EncryptedExtensions、HelloRetryRequest和Certificate消息中发送扩展响应。服务器在CertificateRequest消息中发送扩展请求，客户端可以使用证书消息对其进行响应。服务器也可以在NewSessionTicket中发送未经请求的扩展，尽管客户端不直接响应这些扩展。
Implementations MUST NOT send extension responses if the remote endpoint did not send the corresponding extension requests, with the exception of the "cookie" extension in the HelloRetryRequest. Upon receiving such an extension, an endpoint MUST abort the handshake with an "unsupported_extension" alert.
如果远程端点未发送相应的扩展请求，则实现不得发送扩展响应，HelloRetryRequest中的“cookie”扩展除外。接收到此类扩展后，端点必须使用“unsupported_extension”警报中止握手。
The table below indicates the messages where a given extension may appear, using the following notation: CH (ClientHello), SH (ServerHello), EE (EncryptedExtensions), CT (Certificate), CR (CertificateRequest), NST (NewSessionTicket), and HRR (HelloRetryRequest). If an implementation receives an extension which it recognizes and which is not specified for the message in which it appears, it MUST abort the handshake with an "illegal_parameter" alert.
下表使用以下符号指示给定扩展可能出现的消息：CH（ClientHello）、SH（ServerHello）、EE（EncryptedExtensions）、CT（Certificate）、CR（CertificateRequest）、NST（NewSessionTicket）和HRR（HelloRetryRequest）。如果一个实现接收到一个它可以识别的扩展名，并且该扩展名没有为它出现的消息指定，那么它必须使用“非法参数”警报中止握手。
+--------------------------------------------------+-------------+
| Extension | TLS 1.3 |
+--------------------------------------------------+-------------+
| server_name [RFC6066] | CH, EE |
| | |
| max_fragment_length [RFC6066] | CH, EE |
| | |
| status_request [RFC6066] | CH, CR, CT |
| | |
| supported_groups [RFC7919] | CH, EE |
| | |
| signature_algorithms (RFC 8446) | CH, CR |
| | |
| use_srtp [RFC5764] | CH, EE |
| | |
| heartbeat [RFC6520] | CH, EE |
| | |
| application_layer_protocol_negotiation [RFC7301] | CH, EE |
| | |
| signed_certificate_timestamp [RFC6962] | CH, CR, CT |
| | |
| client_certificate_type [RFC7250] | CH, EE |
| | |
| server_certificate_type [RFC7250] | CH, EE |
| | |
| padding [RFC7685] | CH |
| | |
| key_share (RFC 8446) | CH, SH, HRR |
| | |
| pre_shared_key (RFC 8446) | CH, SH |
| | |
| psk_key_exchange_modes (RFC 8446) | CH |
| | |
| early_data (RFC 8446) | CH, EE, NST |
| | |
| cookie (RFC 8446) | CH, HRR |
| | |
| supported_versions (RFC 8446) | CH, SH, HRR |
| | |
| certificate_authorities (RFC 8446) | CH, CR |
| | |
| oid_filters (RFC 8446) | CR |
| | |
| post_handshake_auth (RFC 8446) | CH |
| | |
| signature_algorithms_cert (RFC 8446) | CH, CR |
+--------------------------------------------------+-------------+
+--------------------------------------------------+-------------+
| Extension | TLS 1.3 |
+--------------------------------------------------+-------------+
| server_name [RFC6066] | CH, EE |
| | |
| max_fragment_length [RFC6066] | CH, EE |
| | |
| status_request [RFC6066] | CH, CR, CT |
| | |
| supported_groups [RFC7919] | CH, EE |
| | |
| signature_algorithms (RFC 8446) | CH, CR |
| | |
| use_srtp [RFC5764] | CH, EE |
| | |
| heartbeat [RFC6520] | CH, EE |
| | |
| application_layer_protocol_negotiation [RFC7301] | CH, EE |
| | |
| signed_certificate_timestamp [RFC6962] | CH, CR, CT |
| | |
| client_certificate_type [RFC7250] | CH, EE |
| | |
| server_certificate_type [RFC7250] | CH, EE |
| | |
| padding [RFC7685] | CH |
| | |
| key_share (RFC 8446) | CH, SH, HRR |
| | |
| pre_shared_key (RFC 8446) | CH, SH |
| | |
| psk_key_exchange_modes (RFC 8446) | CH |
| | |
| early_data (RFC 8446) | CH, EE, NST |
| | |
| cookie (RFC 8446) | CH, HRR |
| | |
| supported_versions (RFC 8446) | CH, SH, HRR |
| | |
| certificate_authorities (RFC 8446) | CH, CR |
| | |
| oid_filters (RFC 8446) | CR |
| | |
| post_handshake_auth (RFC 8446) | CH |
| | |
| signature_algorithms_cert (RFC 8446) | CH, CR |
+--------------------------------------------------+-------------+
When multiple extensions of different types are present, the extensions MAY appear in any order, with the exception of "pre_shared_key" (Section 4.2.11) which MUST be the last extension in the ClientHello (but can appear anywhere in the ServerHello extensions block). There MUST NOT be more than one extension of the same type in a given extension block.
当存在多个不同类型的扩展时，扩展可能以任何顺序出现，但“pre_shared_key”（第4.2.11节）除外，它必须是ClientHello中的最后一个扩展（但可以出现在ServerHello扩展块中的任何位置）。给定扩展块中同一类型的扩展不能超过一个。
In TLS 1.3, unlike TLS 1.2, extensions are negotiated for each handshake even when in resumption-PSK mode. However, 0-RTT parameters are those negotiated in the previous handshake; mismatches may require rejecting 0-RTT (see Section 4.2.10).
在TLS 1.3中，与TLS 1.2不同，每次握手都会协商扩展，即使在恢复PSK模式下也是如此。然而，0-RTT参数是在先前握手中协商的参数；不匹配可能需要拒绝0-RTT（见第4.2.10节）。
There are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which may result in a significant reduction in overall security. The following considerations should be taken into account when designing new extensions:
在本协议中，新功能和现有功能之间可能会发生微妙的（并非如此微妙的）交互，这可能导致整体安全性的显著降低。设计新的扩展时，应考虑以下因素：
- Some cases where a server does not agree to an extension are error conditions (e.g., the handshake cannot continue), and some are simply refusals to support particular features. In general, error alerts should be used for the former and a field in the server extension response for the latter.
- 服务器不同意扩展的某些情况是错误情况（例如，握手无法继续），而有些情况只是拒绝支持特定功能。通常，前者应使用错误警报，后者应使用服务器扩展响应中的字段。
- Extensions should, as far as possible, be designed to prevent any attack that forces use (or non-use) of a particular feature by manipulation of handshake messages. This principle should be followed regardless of whether the feature is believed to cause a security problem. Often the fact that the extension fields are included in the inputs to the Finished message hashes will be sufficient, but extreme care is needed when the extension changes the meaning of messages sent in the handshake phase. Designers and implementors should be aware of the fact that until the handshake has been authenticated, active attackers can modify messages and insert, remove, or replace extensions.
- 扩展的设计应尽可能防止通过操纵握手消息而强制使用（或不使用）特定功能的任何攻击。无论是否认为该功能会导致安全问题，都应遵循此原则。通常，扩展字段包含在完成的消息哈希的输入中就足够了，但是当扩展更改握手阶段发送的消息的含义时，需要格外小心。设计者和实现者应该知道，在握手经过身份验证之前，主动攻击者可以修改消息并插入、删除或替换扩展。
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
The "supported_versions" extension is used by the client to indicate which versions of TLS it supports and by the server to indicate which version it is using. The extension contains a list of supported versions in preference order, with the most preferred version first. Implementations of this specification MUST send this extension in the ClientHello containing all versions of TLS which they are prepared to negotiate (for this specification, that means minimally 0x0304, but if previous versions of TLS are allowed to be negotiated, they MUST be present as well).
客户端使用“supported_versions”扩展来指示它支持的TLS版本，服务器使用“supported_versions”扩展来指示它正在使用的TLS版本。扩展包含按首选项顺序排列的受支持版本的列表，首选版本优先。本规范的实现必须在ClientHello中发送此扩展，其中包含准备协商的所有TLS版本（对于本规范，这意味着最低限度为0x0304，但如果允许协商TLS的以前版本，则必须同时提供）。
If this extension is not present, servers which are compliant with this specification and which also support TLS 1.2 MUST negotiate TLS 1.2 or prior as specified in [RFC5246], even if ClientHello.legacy_version is 0x0304 or later. Servers MAY abort the handshake upon receiving a ClientHello with legacy_version 0x0304 or later.
如果不存在此扩展，则符合本规范且也支持TLS 1.2的服务器必须协商TLS 1.2或[RFC5246]中规定的更早版本，即使ClientHello.legacy_版本为0x0304或更高版本。服务器在接收到旧版本为0x0304或更高版本的ClientHello时可能会中止握手。
If this extension is present in the ClientHello, servers MUST NOT use the ClientHello.legacy_version value for version negotiation and MUST use only the "supported_versions" extension to determine client preferences. Servers MUST only select a version of TLS present in that extension and MUST ignore any unknown versions that are present in that extension. Note that this mechanism makes it possible to negotiate a version prior to TLS 1.2 if one side supports a sparse range. Implementations of TLS 1.3 which choose to support prior versions of TLS SHOULD support TLS 1.2. Servers MUST be prepared to receive ClientHellos that include this extension but do not include 0x0304 in the list of versions.
如果ClientHello中存在此扩展，则服务器不得使用ClientHello.legacy_version值进行版本协商，并且必须仅使用“supported_versions”扩展来确定客户端首选项。服务器必须只选择该扩展中存在的TLS版本，并且必须忽略该扩展中存在的任何未知版本。请注意，如果一方支持稀疏范围，此机制可以协商TLS 1.2之前的版本。选择支持TLS早期版本的TLS 1.3的实现应支持TLS 1.2。服务器必须准备好接收包含此扩展但版本列表中不包含0x0304的ClientHello。
A server which negotiates a version of TLS prior to TLS 1.3 MUST set ServerHello.version and MUST NOT send the "supported_versions" extension. A server which negotiates TLS 1.3 MUST respond by sending a "supported_versions" extension containing the selected version value (0x0304). It MUST set the ServerHello.legacy_version field to 0x0303 (TLS 1.2). Clients MUST check for this extension prior to processing the rest of the ServerHello (although they will have to
协商TLS 1.3之前版本的TLS的服务器必须设置ServerHello.version，并且不得发送“受支持的\u版本”扩展。协商TLS 1.3的服务器必须通过发送包含所选版本值（0x0304）的“受支持的_版本”扩展来响应。它必须将ServerHello.legacy_version字段设置为0x0303（TLS 1.2）。客户端必须在处理ServerHello的其余部分之前检查此扩展（尽管它们必须
parse the ServerHello in order to read the extension). If this extension is present, clients MUST ignore the ServerHello.legacy_version value and MUST use only the "supported_versions" extension to determine the selected version. If the "supported_versions" extension in the ServerHello contains a version not offered by the client or contains a version prior to TLS 1.3, the client MUST abort the handshake with an "illegal_parameter" alert.
解析ServerHello以读取扩展名）。如果存在此扩展，客户端必须忽略ServerHello.legacy_版本值，并且必须仅使用“supported_versions”扩展来确定所选版本。如果ServerHello中的“supported_versions”扩展包含客户端未提供的版本或TLS 1.3之前的版本，则客户端必须使用“非法_参数”警报中止握手。
struct {
opaque cookie<1..2^16-1>;
} Cookie;
struct {
opaque cookie<1..2^16-1>;
} Cookie;
Cookies serve two primary purposes:
Cookie有两个主要用途：
- Allowing the server to force the client to demonstrate reachability at their apparent network address (thus providing a measure of DoS protection). This is primarily useful for non-connection-oriented transports (see [RFC6347] for an example of this).
- 允许服务器强制客户机在其明显的网络地址上显示可达性（从而提供DoS保护措施）。这主要适用于非面向连接的传输（有关此示例，请参见[RFC6347]）。
- Allowing the server to offload state to the client, thus allowing it to send a HelloRetryRequest without storing any state. The server can do this by storing the hash of the ClientHello in the HelloRetryRequest cookie (protected with some suitable integrity protection algorithm).
- 允许服务器将状态卸载到客户端，从而允许它在不存储任何状态的情况下发送HelloRetryRequest。服务器可以通过将ClientHello的散列存储在HelloRetryRequest cookie中（使用适当的完整性保护算法进行保护）来实现这一点。
When sending a HelloRetryRequest, the server MAY provide a "cookie" extension to the client (this is an exception to the usual rule that the only extensions that may be sent are those that appear in the ClientHello). When sending the new ClientHello, the client MUST copy the contents of the extension received in the HelloRetryRequest into a "cookie" extension in the new ClientHello. Clients MUST NOT use cookies in their initial ClientHello in subsequent connections.
发送HelloRetryRequest时，服务器可能会向客户端提供一个“cookie”扩展（这是一个例外，通常的规则是，只能发送ClientHello中出现的扩展）。发送新ClientHello时，客户端必须将HelloRetryRequest中接收到的扩展的内容复制到新ClientHello中的“cookie”扩展中。客户端在后续连接中不得在其初始ClientHello中使用cookie。
When a server is operating statelessly, it may receive an unprotected record of type change_cipher_spec between the first and second ClientHello (see Section 5). Since the server is not storing any state, this will appear as if it were the first message to be received. Servers operating statelessly MUST ignore these records.
当服务器无状态运行时，它可能会在第一个和第二个ClientHello之间收到类型为change\u cipher\u spec的未受保护的记录（参见第5节）。由于服务器未存储任何状态，因此这将显示为第一条要接收的消息。无状态运行的服务器必须忽略这些记录。
TLS 1.3 provides two extensions for indicating which signature algorithms may be used in digital signatures. The "signature_algorithms_cert" extension applies to signatures in certificates, and the "signature_algorithms" extension, which originally appeared in TLS 1.2, applies to signatures in CertificateVerify messages. The keys found in certificates MUST also be of appropriate type for the signature algorithms they are used with. This is a particular issue for RSA keys and PSS signatures, as described below. If no "signature_algorithms_cert" extension is present, then the "signature_algorithms" extension also applies to signatures appearing in certificates. Clients which desire the server to authenticate itself via a certificate MUST send the "signature_algorithms" extension. If a server is authenticating via a certificate and the client has not sent a "signature_algorithms" extension, then the server MUST abort the handshake with a "missing_extension" alert (see Section 9.2).
TLS 1.3提供了两个扩展，用于指示哪些签名算法可用于数字签名。“signature_algorithms_cert”扩展适用于证书中的签名，“signature_algorithms”扩展（最初出现在TLS 1.2中）适用于CertificateVerify消息中的签名。在证书中找到的密钥也必须是与它们一起使用的签名算法的适当类型。这是RSA密钥和PSS签名的一个特殊问题，如下所述。如果不存在“签名算法证书”扩展，则“签名算法”扩展也适用于证书中出现的签名。希望服务器通过证书进行自身身份验证的客户端必须发送“签名算法”扩展。如果服务器正在通过证书进行身份验证，并且客户端尚未发送“签名\u算法”扩展，则服务器必须使用“缺少\u扩展”警报中止握手（请参阅第9.2节）。
The "signature_algorithms_cert" extension was added to allow implementations which supported different sets of algorithms for certificates and in TLS itself to clearly signal their capabilities. TLS 1.2 implementations SHOULD also process this extension. Implementations which have the same policy in both cases MAY omit the "signature_algorithms_cert" extension.
添加了“signature_algorithms_cert”扩展，以允许支持证书和TLS本身的不同算法集的实现清楚地显示其功能。TLS1.2实现也应该处理这个扩展。在这两种情况下具有相同策略的实现可能会忽略“签名\算法\证书”扩展。
The "extension_data" field of these extensions contains a SignatureSchemeList value:
这些扩展的“extension_data”字段包含SignatureSchemeList值：
enum {
/* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601),
enum {
/* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601),
/* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
/* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
/* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_rsae_sha256(0x0804),
rsa_pss_rsae_sha384(0x0805),
rsa_pss_rsae_sha512(0x0806),
/* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_rsae_sha256(0x0804),
rsa_pss_rsae_sha384(0x0805),
rsa_pss_rsae_sha512(0x0806),
/* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),
/* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* Legacy algorithms */
rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203),
/* Legacy algorithms */
rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203),
/* Reserved Code Points */
private_use(0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
/* Reserved Code Points */
private_use(0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
Note: This enum is named "SignatureScheme" because there is already a "SignatureAlgorithm" type in TLS 1.2, which this replaces. We use the term "signature algorithm" throughout the text.
注意：此枚举名为“SignatureScheme”，因为TLS 1.2中已经有一个“SignatureAlgorithm”类型，它将取代该类型。我们在全文中使用术语“签名算法”。
Each SignatureScheme value lists a single signature algorithm that the client is willing to verify. The values are indicated in descending order of preference. Note that a signature algorithm takes as input an arbitrary-length message, rather than a digest. Algorithms which traditionally act on a digest should be defined in TLS to first hash the input with a specified hash algorithm and then proceed as usual. The code point groups listed above have the following meanings:
每个SignatureScheme值都列出了客户端愿意验证的单个签名算法。这些值按首选项的降序显示。请注意，签名算法将任意长度的消息作为输入，而不是摘要。传统上作用于摘要的算法应该在TLS中定义，首先使用指定的哈希算法对输入进行哈希，然后像往常一样继续。上面列出的代码点组具有以下含义：
RSASSA-PKCS1-v1_5 algorithms: Indicates a signature algorithm using RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm as defined in [SHS]. These values refer solely to signatures which appear in certificates (see Section 4.4.2.2) and are not defined for use in signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2.
RSASSA-PKCS1-v1_5算法：表示使用RSASSA-PKCS1-v1_5[RFC8017]和[SHS]中定义的相应哈希算法的签名算法。这些值仅指出现在证书中的签名（见第4.4.2.2节），未定义用于签名TLS握手消息，尽管它们可能出现在“签名算法”和“签名算法证书”中，以便与TLS 1.2向后兼容。
ECDSA algorithms: Indicates a signature algorithm using ECDSA [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA] and FIPS 186-4 [DSS], and the corresponding hash algorithm as defined in [SHS]. The signature is represented as a DER-encoded [X690] ECDSA-Sig-Value structure.
ECDSA算法：表示使用ECDSA[ECDSA]的签名算法、ANSI X9.62[ECDSA]和FIPS 186-4[DSS]中定义的相应曲线以及[SHS]中定义的相应哈希算法。签名表示为DER编码的[X690]ECDSA Sig值结构。
RSASSA-PSS RSAE algorithms: Indicates a signature algorithm using RSASSA-PSS [RFC8017] with mask generation function 1. The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in [SHS]. The length of the Salt MUST be equal to the length of the output of the digest algorithm. If the public key is carried in an X.509 certificate, it MUST use the rsaEncryption OID [RFC5280].
RSASSA-PSS RSAE算法：表示使用带掩码生成功能1的RSASSA-PSS[RFC8017]的签名算法。掩码生成函数中使用的摘要和正在签名的摘要都是[SHS]中定义的相应哈希算法。Salt的长度必须等于摘要算法输出的长度。如果公钥包含在X.509证书中，则必须使用RSAOID加密[RFC5280]。
EdDSA algorithms: Indicates a signature algorithm using EdDSA as defined in [RFC8032] or its successors. Note that these correspond to the "PureEdDSA" algorithms and not the "prehash" variants.
EdDSA算法：表示使用[RFC8032]中定义的EdDSA的签名算法或其后续算法。请注意，这些对应于“PureEdDSA”算法，而不是“prehash”变体。
RSASSA-PSS PSS algorithms: Indicates a signature algorithm using RSASSA-PSS [RFC8017] with mask generation function 1. The digest used in the mask generation function and the digest being signed are both the corresponding hash algorithm as defined in [SHS]. The length of the Salt MUST be equal to the length of the digest algorithm. If the public key is carried in an X.509 certificate, it MUST use the RSASSA-PSS OID [RFC5756]. When used in certificate signatures, the algorithm parameters MUST be DER encoded. If the corresponding public key's parameters are present, then the parameters in the signature MUST be identical to those in the public key.
RSASSA-PSS PSS算法：表示使用带掩码生成功能1的RSASSA-PSS[RFC8017]的签名算法。掩码生成函数中使用的摘要和正在签名的摘要都是[SHS]中定义的相应哈希算法。盐的长度必须等于摘要算法的长度。如果公钥包含在X.509证书中，则必须使用RSASSA-PSS OID[RFC5756]。在证书签名中使用时，必须对算法参数进行DER编码。如果存在相应公钥的参数，则签名中的参数必须与公钥中的参数相同。
Legacy algorithms: Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used in this context with either (1) RSA using RSASSA-PKCS1-v1_5 or (2) ECDSA. These values refer solely to signatures which appear in certificates (see Section 4.4.2.2) and are not defined for use in signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2. Endpoints SHOULD NOT negotiate these algorithms but are permitted to do so solely for backward compatibility. Clients offering these values MUST list them as the lowest priority (listed after all other algorithms in SignatureSchemeList). TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless no valid certificate chain can be produced without it (see Section 4.4.2.2).
遗留算法：表示由于使用具有已知弱点的算法而被弃用的算法，特别是SHA-1，该算法在此上下文中与（1）使用RSASSA-PKCS1-v1_5的RSA或（2）ECDSA一起使用。这些值仅指出现在证书中的签名（见第4.4.2.2节），未定义用于签名TLS握手消息，尽管它们可能出现在“签名算法”和“签名算法证书”中，以便与TLS 1.2向后兼容。端点不应该协商这些算法，但允许这样做只是为了向后兼容。提供这些值的客户端必须将它们列为最低优先级（在SignatureSchemeList中的所有其他算法之后列出）。TLS 1.3服务器不得提供SHA-1签名证书，除非没有该证书就无法生成有效的证书链（见第4.4.2.2节）。
The signatures on certificates that are self-signed or certificates that are trust anchors are not validated, since they begin a certification path (see [RFC5280], Section 3.2). A certificate that begins a certification path MAY use a signature algorithm that is not advertised as being supported in the "signature_algorithms" extension.
自签名证书或作为信任锚的证书上的签名未经验证，因为它们开始于证书路径（请参见[RFC5280]，第3.2节）。开始证书路径的证书可以使用未在“signature_algorithms”扩展中公布为受支持的签名算法。
Note that TLS 1.2 defines this extension differently. TLS 1.3 implementations willing to negotiate TLS 1.2 MUST behave in accordance with the requirements of [RFC5246] when negotiating that version. In particular:
请注意，TLS1.2对该扩展的定义不同。愿意协商TLS 1.2的TLS 1.3实现在协商该版本时，必须按照[RFC5246]的要求行事。特别地：
- TLS 1.2 ClientHellos MAY omit this extension.
- TLS 1.2 ClientHellos可能会忽略此扩展。
- In TLS 1.2, the extension contained hash/signature pairs. The pairs are encoded in two octets, so SignatureScheme values have been allocated to align with TLS 1.2's encoding. Some legacy pairs are left unallocated. These algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or negotiated by any implementation. In particular, MD5 [SLOTH], SHA-224, and DSA MUST NOT be used.
- 在TLS1.2中，扩展包含哈希/签名对。这些对以两个八位字节编码，因此已分配SignatureScheme值以与TLS 1.2的编码对齐。某些遗留对未分配。从TLS 1.3开始，这些算法已被弃用。不得由任何执行机构提供或协商。特别是，不得使用MD5[SLOTH]、SHA-224和DSA。
- ECDSA signature schemes align with TLS 1.2's ECDSA hash/signature pairs. However, the old semantics did not constrain the signing curve. If TLS 1.2 is negotiated, implementations MUST be prepared to accept a signature that uses any curve that they advertised in the "supported_groups" extension.
- ECDSA签名方案与TLS 1.2的ECDSA哈希/签名对对齐。然而，旧的语义并没有约束签名曲线。如果TLS 1.2经过协商，则实现必须准备接受使用其在“受支持的_组”扩展中公布的任何曲线的签名。
- Implementations that advertise support for RSASSA-PSS (which is mandatory in TLS 1.3) MUST be prepared to accept a signature using that scheme even when TLS 1.2 is negotiated. In TLS 1.2, RSASSA-PSS is used with RSA cipher suites.
- 宣传支持RSASSA-PSS（在TLS 1.3中是强制性的）的实现必须准备好接受使用该方案的签名，即使在协商TLS 1.2时也是如此。在TLS 1.2中，RSASSA-PSS与RSA密码套件一起使用。
The "certificate_authorities" extension is used to indicate the certificate authorities (CAs) which an endpoint supports and which SHOULD be used by the receiving endpoint to guide certificate selection.
“certificate_Authority”扩展用于指示端点支持的证书颁发机构（CA），接收端点应使用这些证书颁发机构来指导证书选择。
The body of the "certificate_authorities" extension consists of a CertificateAuthoritiesExtension structure.
“certificate_Authority”扩展的主体由CertificateAuthorities扩展结构组成。
opaque DistinguishedName<1..2^16-1>;
opaque DistinguishedName<1..2^16-1>;
struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;
struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;
authorities: A list of the distinguished names [X501] of acceptable certificate authorities, represented in DER-encoded [X690] format. These distinguished names specify a desired distinguished name for a trust anchor or subordinate CA; thus, this message can be used to describe known trust anchors as well as a desired authorization space.
授权机构：可接受证书授权机构的可分辨名称[X501]列表，以DER编码的[X690]格式表示。这些可分辨名称为信任锚或从属CA指定所需的可分辨名称；因此，该消息可用于描述已知的信任锚以及所需的授权空间。
The client MAY send the "certificate_authorities" extension in the ClientHello message. The server MAY send it in the CertificateRequest message.
客户端可以在ClientHello消息中发送“certificate\u Authority”扩展。服务器可以在CertificateRequest消息中发送它。
The "trusted_ca_keys" extension [RFC6066], which serves a similar purpose but is more complicated, is not used in TLS 1.3 (although it may appear in ClientHello messages from clients which are offering prior versions of TLS).
TLS 1.3中未使用“trusted_ca_keys”扩展[RFC6066]，该扩展具有类似的用途，但更为复杂（尽管它可能出现在提供TLS早期版本的客户端的ClientHello消息中）。
The "oid_filters" extension allows servers to provide a set of OID/value pairs which it would like the client's certificate to match. This extension, if provided by the server, MUST only be sent in the CertificateRequest message.
“oid_filters”扩展允许服务器提供一组它希望客户端证书匹配的oid/值对。如果此扩展由服务器提供，则只能在CertificateRequest消息中发送。
struct {
opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} OIDFilter;
struct {
opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} OIDFilter;
struct {
OIDFilter filters<0..2^16-1>;
} OIDFilterExtension;
struct {
OIDFilter filters<0..2^16-1>;
} OIDFilterExtension;
filters: A list of certificate extension OIDs [RFC5280] with their allowed value(s) and represented in DER-encoded [X690] format. Some certificate extension OIDs allow multiple values (e.g., Extended Key Usage). If the server has included a non-empty filters list, the client certificate included in the response MUST contain all of the specified extension OIDs that the client recognizes. For each extension OID recognized by the client, all of the specified values MUST be present in the client certificate (but the certificate MAY have other values as well). However, the client MUST ignore and skip any unrecognized certificate extension OIDs. If the client ignored some of the required certificate extension OIDs and supplied a certificate that does not satisfy the request, the server MAY at its discretion either continue the connection without client authentication or abort the handshake with an "unsupported_certificate" alert. Any given OID MUST NOT appear more than once in the filters list.
筛选器：证书扩展OID[RFC5280]列表及其允许值，并以DER编码的[X690]格式表示。一些证书扩展OID允许多个值（例如，扩展密钥使用）。如果服务器包含非空筛选器列表，则响应中包含的客户端证书必须包含客户端识别的所有指定扩展OID。对于客户端识别的每个扩展OID，客户端证书中必须存在所有指定的值（但证书也可能有其他值）。但是，客户端必须忽略并跳过任何无法识别的证书扩展OID。如果客户端忽略了某些必需的证书扩展OID并提供了不满足请求的证书，则服务器可自行决定在不进行客户端身份验证的情况下继续连接，或使用“不支持的\u证书”警报中止握手。任何给定OID在筛选器列表中不得出现多次。
PKIX RFCs define a variety of certificate extension OIDs and their corresponding value types. Depending on the type, matching certificate extension values are not necessarily bitwise-equal. It is expected that TLS implementations will rely on their PKI libraries to perform certificate selection using certificate extension OIDs.
PKIX RFC定义了各种证书扩展OID及其相应的值类型。根据类型，匹配的证书扩展值不一定按位相等。预计TLS实现将依靠其PKI库使用证书扩展OID执行证书选择。
This document defines matching rules for two standard certificate extensions defined in [RFC5280]:
本文档为[RFC5280]中定义的两个标准证书扩展定义了匹配规则：
- The Key Usage extension in a certificate matches the request when all key usage bits asserted in the request are also asserted in the Key Usage certificate extension.
- 当请求中断言的所有密钥使用位也在密钥使用证书扩展中断言时，证书中的密钥使用扩展与请求匹配。
- The Extended Key Usage extension in a certificate matches the request when all key purpose OIDs present in the request are also found in the Extended Key Usage certificate extension. The special anyExtendedKeyUsage OID MUST NOT be used in the request.
- 当在扩展密钥使用证书扩展中也找到请求中存在的所有密钥用途ID时，证书中的扩展密钥使用扩展与请求匹配。请求中不得使用特殊的anyExtendedKeyUsage OID。
Separate specifications may define matching rules for other certificate extensions.
单独的规范可以定义其他证书扩展的匹配规则。
The "post_handshake_auth" extension is used to indicate that a client is willing to perform post-handshake authentication (Section 4.6.2). Servers MUST NOT send a post-handshake CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension.
“post_handshake_auth”扩展用于表示客户端愿意执行握手后身份验证（第4.6.2节）。服务器不得向不提供此扩展的客户端发送握手后证书请求。服务器不能发送此扩展名。
struct {} PostHandshakeAuth;
struct {} PostHandshakeAuth;
The "extension_data" field of the "post_handshake_auth" extension is zero length.
“post_handshake_auth”扩展的“extension_data”字段长度为零。
When sent by the client, the "supported_groups" extension indicates the named groups which the client supports for key exchange, ordered from most preferred to least preferred.
由客户端发送时，“supported_groups”扩展名表示客户端支持密钥交换的命名组，按从最优先到最不优先的顺序排列。
Note: In versions of TLS prior to TLS 1.3, this extension was named "elliptic_curves" and only contained elliptic curve groups. See [RFC8422] and [RFC7919]. This extension was also used to negotiate ECDSA curves. Signature algorithms are now negotiated independently (see Section 4.2.3).
注意：在TLS1.3之前的TLS版本中，此扩展名为“椭圆曲线”，仅包含椭圆曲线组。参见[RFC8422]和[RFC7919]。此扩展还用于协商ECDSA曲线。签名算法现在独立协商（见第4.2.3节）。
The "extension_data" field of this extension contains a "NamedGroupList" value:
此扩展的“扩展数据”字段包含“NamedGroupList”值：
enum {
enum {
/* Elliptic Curve Groups (ECDHE) */
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
x25519(0x001D), x448(0x001E),
/* Elliptic Curve Groups (ECDHE) */
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
(0xFFFF)
} NamedGroup;
/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
(0xFFFF)
} NamedGroup;
struct {
NamedGroup named_group_list<2..2^16-1>;
} NamedGroupList;
struct {
NamedGroup named_group_list<2..2^16-1>;
} NamedGroupList;
Elliptic Curve Groups (ECDHE): Indicates support for the corresponding named curve, defined in either FIPS 186-4 [DSS] or [RFC7748]. Values 0xFE00 through 0xFEFF are reserved for Private Use [RFC8126].
椭圆曲线组（ECDHE）：表示支持FIPS 186-4[DSS]或[RFC7748]中定义的相应命名曲线。值0xFE00到0xFEFF保留供私人使用[RFC8126]。
Finite Field Groups (DHE): Indicates support for the corresponding finite field group, defined in [RFC7919]. Values 0x01FC through 0x01FF are reserved for Private Use.
有限域组（DHE）：表示支持[RFC7919]中定义的相应有限域组。值0x01FC到0x01FF保留供私人使用。
Items in named_group_list are ordered according to the sender's preferences (most preferred choice first).
命名组列表中的项目根据发件人的首选项排序（首选项优先）。
As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client. Clients MUST NOT act upon any information found in "supported_groups" prior to successful completion of the handshake but MAY use the information learned from a successfully completed handshake to change what groups they use in their "key_share" extension in subsequent connections. If the server has a group it prefers to the ones in the "key_share" extension but is still willing to accept the ClientHello, it SHOULD send "supported_groups" to update the client's view of its preferences; this extension SHOULD contain all groups the server supports, regardless of whether they are currently supported by the client.
从TLS 1.3开始，允许服务器向客户端发送“受支持的_组”扩展。在成功完成握手之前，客户端不得对“受支持的组”中的任何信息采取行动，但可以使用从成功完成的握手中获得的信息来更改其在后续连接中的“密钥共享”扩展中使用的组。如果服务器有一个组，而不是“密钥共享”扩展中的组，但仍愿意接受ClientHello，则应发送“受支持的\u组”以更新客户端对其首选项的视图；此扩展应包含服务器支持的所有组，无论客户端当前是否支持这些组。
The "key_share" extension contains the endpoint's cryptographic parameters.
“密钥共享”扩展包含端点的加密参数。
Clients MAY send an empty client_shares vector in order to request group selection from the server, at the cost of an additional round trip (see Section 4.1.4).
客户端可以发送一个空的客户端共享向量，以便从服务器请求组选择，代价是额外的往返（参见第4.1.4节）。
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
group: The named group for the key being exchanged.
组：正在交换的密钥的命名组。
key_exchange: Key exchange information. The contents of this field are determined by the specified group and its corresponding definition. Finite Field Diffie-Hellman [DH76] parameters are described in Section 4.2.8.1; Elliptic Curve Diffie-Hellman parameters are described in Section 4.2.8.2.
密钥交换：密钥交换信息。此字段的内容由指定的组及其相应的定义确定。第4.2.8.1节描述了有限域Diffie-Hellman[DH76]参数；椭圆曲线Diffie-Hellman参数见第4.2.8.2节。
In the ClientHello message, the "extension_data" field of this extension contains a "KeyShareClientHello" value:
在ClientHello消息中，此扩展的“extension_data”字段包含一个“KeyShareClientHello”值：
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
client_shares: A list of offered KeyShareEntry values in descending order of client preference.
客户共享：按客户偏好降序排列的提供的密钥共享值列表。
This vector MAY be empty if the client is requesting a HelloRetryRequest. Each KeyShareEntry value MUST correspond to a group offered in the "supported_groups" extension and MUST appear in the same order. However, the values MAY be a non-contiguous subset of the "supported_groups" extension and MAY omit the most preferred groups. Such a situation could arise if the most preferred groups are new and unlikely to be supported in enough places to make pregenerating key shares for them efficient.
如果客户端请求HelloRetryRequest，则此向量可能为空。每个KeyShareEntry值必须对应于“supported_groups”扩展中提供的组，并且必须以相同的顺序出现。然而，这些值可以是“受支持的组”扩展的非连续子集，并且可以省略最优选的组。如果最受欢迎的群体是新的群体，并且不太可能在足够的地方得到支持，从而使他们的预生成关键股票变得高效，则可能出现这种情况。
Clients can offer as many KeyShareEntry values as the number of supported groups it is offering, each representing a single set of key exchange parameters. For instance, a client might offer shares for several elliptic curves or multiple FFDHE groups. The key_exchange values for each KeyShareEntry MUST be generated independently. Clients MUST NOT offer multiple KeyShareEntry values for the same group. Clients MUST NOT offer any KeyShareEntry values for groups not listed in the client's "supported_groups" extension. Servers MAY check for violations of these rules and abort the handshake with an "illegal_parameter" alert if one is violated.
客户机可以提供与其所提供的受支持组数量相同的密钥共享值，每个组表示一组密钥交换参数。例如，一个客户可能会为几个椭圆曲线或多个FFDHE组提供共享。每个密钥共享的密钥交换值必须独立生成。客户端不能为同一组提供多个密钥共享值。客户端不得为未在客户端的“受支持的组”扩展中列出的组提供任何密钥共享值。服务器可能会检查是否违反了这些规则，并在违反规则时发出“非法_参数”警报中止握手。
In a HelloRetryRequest message, the "extension_data" field of this extension contains a KeyShareHelloRetryRequest value:
在HelloRetryRequest消息中，此扩展的“extension_data”字段包含一个KeyShareHelloRetryRequest值：
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
selected_group: The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for.
selected_group：服务器打算协商并请求重试ClientHello/KeyShare的相互支持的组。
Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that (1) the selected_group field corresponds to a group which was provided in the "supported_groups" extension in the original ClientHello and (2) the selected_group field does not correspond to a group which was provided in the "key_share" extension in the original ClientHello. If either of these checks fails, then the client MUST abort the handshake with an "illegal_parameter" alert. Otherwise, when sending the new ClientHello, the client MUST
在HelloRetryRequest中收到此扩展后，客户端必须验证（1）所选的\u组字段是否对应于原始ClientHello中“受支持的\u组”扩展中提供的组，以及（2）所选的\u组字段是否对应于“密钥\u共享”中提供的组原始ClientHello中的扩展。如果这些检查中的任何一个失败，那么客户端必须使用“非法_参数”警报中止握手。否则，在发送新ClientHello时，客户端必须
replace the original "key_share" extension with one containing only a new KeyShareEntry for the group indicated in the selected_group field of the triggering HelloRetryRequest.
将原始的“密钥共享”扩展名替换为仅包含触发HelloRetryRequest的selected_group字段中所示组的新密钥共享名的扩展名。
In a ServerHello message, the "extension_data" field of this extension contains a KeyShareServerHello value:
在ServerHello消息中，此扩展的“extension_data”字段包含一个KeyShareServerHello值：
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
server_share: A single KeyShareEntry value that is in the same group as one of the client's shares.
服务器共享：与客户端共享之一位于同一组中的单个密钥共享值。
If using (EC)DHE key establishment, servers offer exactly one KeyShareEntry in the ServerHello. This value MUST be in the same group as the KeyShareEntry value offered by the client that the server has selected for the negotiated key exchange. Servers MUST NOT send a KeyShareEntry for any group not indicated in the client's "supported_groups" extension and MUST NOT send a KeyShareEntry when using the "psk_ke" PskKeyExchangeMode. If using (EC)DHE key establishment and a HelloRetryRequest containing a "key_share" extension was received by the client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the HelloRetryRequest. If this check fails, the client MUST abort the handshake with an "illegal_parameter" alert.
如果使用（EC）DHE密钥建立，服务器在ServerHello中只提供一个密钥共享。此值必须与服务器为协商密钥交换选择的客户端提供的密钥共享值位于同一组中。服务器不得为客户端的“受支持的组”扩展中未指明的任何组发送密钥共享，并且在使用“psk_ke”PskKeyExchangeMode时不得发送密钥共享。如果客户端接收到使用（EC）DHE密钥建立和包含“密钥共享”扩展名的HelloRetryRequest，则客户端必须验证ServerHello中选定的NamedGroup是否与HelloRetryRequest中的相同。如果此检查失败，客户端必须使用“非法_参数”警报中止握手。
Diffie-Hellman [DH76] parameters for both clients and servers are encoded in the opaque key_exchange field of a KeyShareEntry in a KeyShare structure. The opaque value contains the Diffie-Hellman public value (Y = g^X mod p) for the specified group (see [RFC7919] for group definitions) encoded as a big-endian integer and padded to the left with zeros to the size of p in bytes.
客户机和服务器的Diffie Hellman[DH76]参数都编码在密钥共享结构中密钥共享的不透明密钥交换字段中。不透明值包含指定组的Diffie-Hellman公共值（Y=g^X mod p）（有关组定义，请参见[RFC7919]），该值编码为大端整数，并在左侧用零填充，大小为p（以字节为单位）。
Note: For a given Diffie-Hellman group, the padding results in all public keys having the same length.
注意：对于给定的Diffie-Hellman组，填充会导致所有公钥具有相同的长度。
Peers MUST validate each other's public key Y by ensuring that 1 < Y < p-1. This check ensures that the remote peer is properly behaved and isn't forcing the local system into a small subgroup.
对等方必须通过确保1<Y<p-1来验证彼此的公钥Y。此检查确保远程对等机的行为正确，并且不会将本地系统强制为一个小的子组。
ECDHE parameters for both clients and servers are encoded in the opaque key_exchange field of a KeyShareEntry in a KeyShare structure.
ECDHE客户端和服务器的参数都编码在密钥共享结构中密钥共享的不透明密钥交换字段中。
For secp256r1, secp384r1, and secp521r1, the contents are the serialized value of the following struct:
对于secp256r1、secp384r1和secp521r1，内容是以下结构的序列化值：
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
X and Y, respectively, are the binary representations of the x and y values in network byte order. There are no internal length markers, so each number representation occupies as many octets as implied by the curve parameters. For P-256, this means that each of X and Y use 32 octets, padded on the left by zeros if necessary. For P-384, they take 48 octets each. For P-521, they take 66 octets each.
X和Y分别是X和Y值在网络字节顺序中的二进制表示。没有内部长度标记，因此每个数字表示法占用的八位字节数与曲线参数所暗示的八位字节数相同。对于P-256，这意味着X和Y中的每一个都使用32个八位字节，如有必要，在左边用零填充。对于P-384，它们每个有48个八位组。对于P-521，它们每个有66个八位组。
For the curves secp256r1, secp384r1, and secp521r1, peers MUST
validate each other's public value Q by ensuring that the point is a
valid point on the elliptic curve. The appropriate validation
procedures are defined in Section 4.3.7 of [ECDSA] and alternatively
in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three
steps: (1) verify that Q is not the point at infinity (O), (2) verify
that for Q = (x, y) both integers x and y are in the correct
interval, and (3) ensure that (x, y) is a correct solution to the
elliptic curve equation. For these curves, implementors do not need
to verify membership in the correct subgroup.
For the curves secp256r1, secp384r1, and secp521r1, peers MUST
validate each other's public value Q by ensuring that the point is a
valid point on the elliptic curve. The appropriate validation
procedures are defined in Section 4.3.7 of [ECDSA] and alternatively
in Section 5.6.2.3 of [KEYAGREEMENT]. This process consists of three
steps: (1) verify that Q is not the point at infinity (O), (2) verify
that for Q = (x, y) both integers x and y are in the correct
interval, and (3) ensure that (x, y) is a correct solution to the
elliptic curve equation. For these curves, implementors do not need
to verify membership in the correct subgroup.
For X25519 and X448, the contents of the public value are the byte string inputs and outputs of the corresponding functions defined in [RFC7748]: 32 bytes for X25519 and 56 bytes for X448.
对于X25519和X448，公共值的内容是[RFC7748]中定义的相应函数的字节字符串输入和输出：X25519为32字节，X448为56字节。
Note: Versions of TLS prior to 1.3 permitted point format negotiation; TLS 1.3 removes this feature in favor of a single point format for each curve.
注：1.3许可点格式协商之前的TLS版本；TLS 1.3删除了该功能，支持每条曲线的单点格式。
In order to use PSKs, clients MUST also send a "psk_key_exchange_modes" extension. The semantics of this extension are that the client only supports the use of PSKs with these modes, which restricts both the use of PSKs offered in this ClientHello and those which the server might supply via NewSessionTicket.
为了使用psk，客户端还必须发送“psk密钥交换模式”扩展。此扩展的语义是，客户端仅支持在这些模式下使用PSK，这既限制了此ClientHello中提供的PSK的使用，也限制了服务器可能通过NewSessionTicket提供的PSK的使用。
A client MUST provide a "psk_key_exchange_modes" extension if it offers a "pre_shared_key" extension. If clients offer "pre_shared_key" without a "psk_key_exchange_modes" extension, servers MUST abort the handshake. Servers MUST NOT select a key exchange mode that is not listed by the client. This extension also restricts the modes for use with PSK resumption. Servers SHOULD NOT send NewSessionTicket with tickets that are not compatible with the advertised modes; however, if a server does so, the impact will just be that the client's attempts at resumption fail.
如果客户机提供“预共享密钥”扩展，则必须提供“psk密钥交换模式”扩展。如果客户端提供的“预共享密钥”没有“psk密钥交换模式”扩展，服务器必须中止握手。服务器不得选择客户端未列出的密钥交换模式。此扩展还限制与PSK恢复一起使用的模式。服务器不应发送带有与广告模式不兼容的票证的新闻会话票证；但是，如果服务器这样做，其影响只会是客户端的恢复尝试失败。
The server MUST NOT send a "psk_key_exchange_modes" extension.
服务器不得发送“psk密钥交换模式”扩展名。
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct {
PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes;
struct {
PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes;
psk_ke: PSK-only key establishment. In this mode, the server MUST NOT supply a "key_share" value.
psk_ke：仅psk密钥建立。在此模式下，服务器不得提供“密钥共享”值。
psk_dhe_ke: PSK with (EC)DHE key establishment. In this mode, the client and server MUST supply "key_share" values as described in Section 4.2.8.
psk_dhe_ke:psk与（EC）dhe密钥建立。在此模式下，客户端和服务器必须提供第4.2.8节所述的“密钥共享”值。
Any future values that are allocated must ensure that the transmitted protocol messages unambiguously identify which mode was selected by the server; at present, this is indicated by the presence of the "key_share" in the ServerHello.
分配的任何未来值必须确保传输的协议消息明确标识服务器选择的模式；目前，服务器Hello中存在“密钥共享”表明了这一点。
When a PSK is used and early data is allowed for that PSK, the client can send Application Data in its first flight of messages. If the client opts to do so, it MUST supply both the "pre_shared_key" and "early_data" extensions.
当使用PSK并且允许该PSK使用早期数据时，客户端可以在其第一个消息段中发送应用程序数据。如果客户端选择这样做，它必须同时提供“pre_shared_key”和“early_data”扩展。
The "extension_data" field of this extension contains an "EarlyDataIndication" value.
此扩展的“扩展数据”字段包含“EarlyDataIndication”值。
struct {} Empty;
struct {} Empty;
struct {
select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty;
case encrypted_extensions: Empty;
};
} EarlyDataIndication;
struct {
select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty;
case encrypted_extensions: Empty;
};
} EarlyDataIndication;
See Section 4.6.1 for details regarding the use of the max_early_data_size field.
有关使用最大早期数据大小字段的详细信息，请参见第4.6.1节。
The parameters for the 0-RTT data (version, symmetric cipher suite, Application-Layer Protocol Negotiation (ALPN) [RFC7301] protocol, etc.) are those associated with the PSK in use. For externally provisioned PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK. The PSK used to encrypt the early data MUST be the first PSK listed in the client's "pre_shared_key" extension.
0-RTT数据的参数（版本、对称密码套件、应用层协议协商（ALPN）[RFC7301]协议等）与正在使用的PSK相关。对于外部配置的PSK，关联的值是与密钥一起配置的值。对于通过NewSessionTicket消息建立的PSK，关联值是在建立PSK的连接中协商的值。用于加密早期数据的PSK必须是客户端“pre_shared_key”扩展中列出的第一个PSK。
For PSKs provisioned via NewSessionTicket, a server MUST validate that the ticket age for the selected PSK identity (computed by subtracting ticket_age_add from PskIdentity.obfuscated_ticket_age modulo 2^32) is within a small tolerance of the time since the ticket was issued (see Section 8). If it is not, the server SHOULD proceed with the handshake but reject 0-RTT, and SHOULD NOT take any other action that assumes that this ClientHello is fresh.
对于通过NewSessionTicket配置的PSK，服务器必须验证所选PSK标识的票龄（通过从PskIdentity.obfuscated票龄模2^32中减去票龄添加来计算）是否在自票证发布以来的较小时间容差内（见第8节）。如果不是，服务器应继续握手，但拒绝0-RTT，并且不应采取任何其他假定此ClientHello是新的操作。
0-RTT messages sent in the first flight have the same (encrypted) content types as messages of the same type sent in other flights (handshake and application_data) but are protected under different keys. After receiving the server's Finished message, if the server has accepted early data, an EndOfEarlyData message will be sent to indicate the key change. This message will be encrypted with the 0-RTT traffic keys.
在第一次航班中发送的0-RTT消息与在其他航班中发送的相同类型的消息（握手和应用程序_数据）具有相同的（加密）内容类型，但受到不同密钥的保护。在收到服务器的完成消息后，如果服务器已接受早期数据，则将发送EndOfEarlyData消息以指示密钥更改。此消息将使用0-RTT通信密钥加密。
A server which receives an "early_data" extension MUST behave in one of three ways:
接收“早期数据”扩展的服务器必须以以下三种方式之一运行：
- Ignore the extension and return a regular 1-RTT response. The server then skips past early data by attempting to deprotect received records using the handshake traffic key, discarding records which fail deprotection (up to the configured max_early_data_size). Once a record is deprotected successfully, it is treated as the start of the client's second flight and the server proceeds as with an ordinary 1-RTT handshake.
- 忽略扩展并返回常规的1-RTT响应。然后，服务器通过尝试使用握手通信密钥解除对接收到的记录的保护而跳过早期数据，丢弃未能解除保护的记录（最大为配置的最大早期数据大小）。一旦记录成功解除保护，它将被视为客户端第二次飞行的开始，服务器将继续进行普通的1-RTT握手。
- Request that the client send another ClientHello by responding with a HelloRetryRequest. A client MUST NOT include the "early_data" extension in its followup ClientHello. The server then ignores early data by skipping all records with an external content type of "application_data" (indicating that they are encrypted), up to the configured max_early_data_size.
- 请求客户端通过响应HelloRetryRequest发送另一个ClientHello。客户端不得在其后续ClientHello中包含“early_data”扩展。然后，服务器将跳过外部内容类型为“应用程序数据”（表示已加密）的所有记录，忽略早期数据，直至配置的最大早期数据大小。
- Return its own "early_data" extension in EncryptedExtensions, indicating that it intends to process the early data. It is not possible for the server to accept only a subset of the early data messages. Even though the server sends a message accepting early data, the actual early data itself may already be in flight by the time the server generates this message.
- 在EncryptedExtensions中返回它自己的“early_data”扩展名，表示它打算处理早期数据。服务器不可能只接受早期数据消息的一个子集。即使服务器发送一条接受早期数据的消息，但在服务器生成此消息时，实际的早期数据本身可能已经在传输中。
In order to accept early data, the server MUST have accepted a PSK cipher suite and selected the first key offered in the client's "pre_shared_key" extension. In addition, it MUST verify that the following values are the same as those associated with the selected PSK:
为了接受早期数据，服务器必须已接受PSK密码套件，并选择客户端的“pre_shared_key”扩展中提供的第一个密钥。此外，必须验证以下值是否与所选PSK相关的值相同：
- The TLS version number
- TLS版本号
- The selected cipher suite
- 选定的密码套件
- The selected ALPN [RFC7301] protocol, if any
- 所选的ALPN[RFC7301]协议（如果有）
These requirements are a superset of those needed to perform a 1-RTT handshake using the PSK in question. For externally established PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those negotiated in the connection during which the ticket was established.
这些需求是使用所讨论的PSK执行1-RTT握手所需需求的超集。对于外部建立的PSK，相关值是随密钥一起提供的值。对于通过NewSessionTicket消息建立的PSK，关联值是在建立票证的连接中协商的值。
Future extensions MUST define their interaction with 0-RTT.
未来的扩展必须定义它们与0-RTT的交互。
If any of these checks fail, the server MUST NOT respond with the extension and must discard all the first-flight data using one of the first two mechanisms listed above (thus falling back to 1-RTT or 2-RTT). If the client attempts a 0-RTT handshake but the server rejects it, the server will generally not have the 0-RTT record protection keys and must instead use trial decryption (either with the 1-RTT handshake keys or by looking for a cleartext ClientHello in the case of a HelloRetryRequest) to find the first non-0-RTT message.
如果这些检查中的任何一项失败，服务器不得响应扩展，必须使用上面列出的前两种机制之一丢弃所有首飞数据（因此返回到1-RTT或2-RTT）。如果客户端尝试0-RTT握手，但服务器拒绝，则服务器通常不具有0-RTT记录保护密钥，而必须使用尝试解密（使用1-RTT握手密钥或在HelloRetryRequest情况下通过查找明文ClientHello）来查找第一条非0-RTT消息。
If the server chooses to accept the "early_data" extension, then it MUST comply with the same error-handling requirements specified for all records when processing early data records. Specifically, if the server fails to decrypt a 0-RTT record following an accepted "early_data" extension, it MUST terminate the connection with a "bad_record_mac" alert as per Section 5.2.
如果服务器选择接受“早期数据”扩展，则在处理早期数据记录时，它必须遵守为所有记录指定的相同错误处理要求。具体而言，如果服务器在接受“早期数据”扩展后未能解密0-RTT记录，则必须根据第5.2节的规定，使用“坏记录\u mac”警报终止连接。
If the server rejects the "early_data" extension, the client application MAY opt to retransmit the Application Data previously sent in early data once the handshake has been completed. Note that automatic retransmission of early data could result in incorrect assumptions regarding the status of the connection. For instance, when the negotiated connection selects a different ALPN protocol from what was used for the early data, an application might need to construct different messages. Similarly, if early data assumes anything about the connection state, it might be sent in error after the handshake completes.
如果服务器拒绝“早期数据”扩展，则一旦握手完成，客户端应用程序可以选择重新传输先前在早期数据中发送的应用程序数据。请注意，自动重新传输早期数据可能会导致对连接状态的错误假设。例如，当协商连接从早期数据中选择不同的ALPN协议时，应用程序可能需要构造不同的消息。类似地，如果早期数据假设连接状态，那么在握手完成后可能会错误地发送。
A TLS implementation SHOULD NOT automatically resend early data; applications are in a better position to decide when retransmission is appropriate. A TLS implementation MUST NOT automatically resend early data unless the negotiated connection selects the same ALPN protocol.
TLS实施不应自动重新发送早期数据；应用程序可以更好地决定何时适合重新传输。TLS实现不得自动重新发送早期数据，除非协商连接选择相同的ALPN协议。
The "pre_shared_key" extension is used to negotiate the identity of the pre-shared key to be used with a given handshake in association with PSK key establishment.
“预共享密钥”扩展用于协商与PSK密钥建立相关联的给定握手使用的预共享密钥的身份。
The "extension_data" field of this extension contains a "PreSharedKeyExtension" value:
此扩展的“扩展\数据”字段包含“PreSharedKeyExtension”值：
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
} PskIdentity;
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
} PskIdentity;
opaque PskBinderEntry<32..255>;
opaque PskBinderEntry<32..255>;
struct {
PskIdentity identities<7..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;
struct {
PskIdentity identities<7..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;
struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;
struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;
identity: A label for a key. For instance, a ticket (as defined in Appendix B.3.4) or a label for a pre-shared key established externally.
标识：密钥的标签。例如，外部建立的预共享密钥的票证（定义见附录B.3.4）或标签。
obfuscated_ticket_age: An obfuscated version of the age of the key. Section 4.2.11.1 describes how to form this value for identities established via the NewSessionTicket message. For identities established externally, an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value.
模糊的\u票证\u年龄：密钥年龄的模糊版本。第4.2.11.1节描述了如何为通过NewSessionTicket消息建立的身份形成该值。对于在外部建立的标识，应使用模糊的\u票证\u年龄0，服务器必须忽略该值。
identities: A list of the identities that the client is willing to negotiate with the server. If sent alongside the "early_data" extension (see Section 4.2.10), the first identity is the one used for 0-RTT data.
标识：客户机愿意与服务器协商的标识列表。如果与“早期数据”扩展一起发送（见第4.2.10节），则第一个标识是用于0-RTT数据的标识。
binders: A series of HMAC values, one for each value in the identities list and in the same order, computed as described below.
绑定：一系列HMAC值，标识列表中每个值一个，顺序相同，计算如下。
selected_identity: The server's chosen identity expressed as a (0-based) index into the identities in the client's list.
selected_identity：服务器选择的标识，表示为客户端列表中标识的（基于0的）索引。
Each PSK is associated with a single Hash algorithm. For PSKs established via the ticket mechanism (Section 4.6.1), this is the KDF Hash algorithm on the connection where the ticket was established. For externally established PSKs, the Hash algorithm MUST be set when
每个PSK都与一个散列算法相关联。对于通过票证机制（第4.6.1节）建立的PSK，这是建立票证的连接上的KDF哈希算法。对于外部建立的PSK，必须在以下情况下设置哈希算法：
the PSK is established or default to SHA-256 if no such algorithm is defined. The server MUST ensure that it selects a compatible PSK (if any) and cipher suite.
PSK已建立，如果未定义此类算法，则默认为SHA-256。服务器必须确保选择兼容的PSK（如果有）和密码套件。
In TLS versions prior to TLS 1.3, the Server Name Identification (SNI) value was intended to be associated with the session (Section 3 of [RFC6066]), with the server being required to enforce that the SNI value associated with the session matches the one specified in the resumption handshake. However, in reality the implementations were not consistent on which of two supplied SNI values they would use, leading to the consistency requirement being de facto enforced by the clients. In TLS 1.3, the SNI value is always explicitly specified in the resumption handshake, and there is no need for the server to associate an SNI value with the ticket. Clients, however, SHOULD store the SNI with the PSK to fulfill the requirements of Section 4.6.1.
在TLS 1.3之前的TLS版本中，服务器名称标识（SNI）值旨在与会话关联（RFC6066）第3节），要求服务器强制执行与会话关联的SNI值与恢复握手中指定的值匹配。然而，在现实中，实现并不一致，它们将使用两个提供的SNI值中的哪一个，这导致客户机事实上强制执行一致性要求。在TLS 1.3中，SNI值始终在恢复握手中明确指定，服务器无需将SNI值与票据关联。但是，客户应将SNI与PSK一起存储，以满足第4.6.1节的要求。
Implementor's note: When session resumption is the primary use case of PSKs, the most straightforward way to implement the PSK/cipher suite matching requirements is to negotiate the cipher suite first and then exclude any incompatible PSKs. Any unknown PSKs (e.g., ones not in the PSK database or encrypted with an unknown key) SHOULD simply be ignored. If no acceptable PSKs are found, the server SHOULD perform a non-PSK handshake if possible. If backward compatibility is important, client-provided, externally established PSKs SHOULD influence cipher suite selection.
实施者注意：当会话恢复是PSK的主要用例时，实现PSK/密码套件匹配要求的最直接方法是首先协商密码套件，然后排除任何不兼容的PSK。任何未知的PSK（例如，不在PSK数据库中或使用未知密钥加密的PSK）都应忽略。如果没有找到可接受的PSK，服务器应尽可能执行非PSK握手。如果向后兼容性很重要，客户机提供的、外部建立的PSK应该会影响密码套件的选择。
Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.2.11.2 below). If this value is not present or does not validate, the server MUST abort the handshake. Servers SHOULD NOT attempt to validate multiple binders; rather, they SHOULD select a single PSK and validate solely the binder that corresponds to that PSK. See Section 8.2 and Appendix E.6 for the security rationale for this requirement. In order to accept PSK key establishment, the server sends a "pre_shared_key" extension indicating the selected identity.
在接受PSK密钥建立之前，服务器必须验证相应的绑定值（见下文第4.2.11.2节）。如果此值不存在或未验证，服务器必须中止握手。服务器不应尝试验证多个绑定；相反，他们应该选择一个单独的PSK，并单独验证与该PSK对应的活页夹。有关此要求的安全理由，请参见第8.2节和附录E.6。为了接受PSK密钥建立，服务器发送一个“pre_shared_key”扩展名，指示所选标识。
Clients MUST verify that the server's selected_identity is within the range supplied by the client, that the server selected a cipher suite indicating a Hash associated with the PSK, and that a server "key_share" extension is present if required by the ClientHello "psk_key_exchange_modes" extension. If these values are not consistent, the client MUST abort the handshake with an "illegal_parameter" alert.
客户端必须验证服务器选择的\u标识是否在客户端提供的范围内，服务器是否选择了指示与PSK关联的哈希的密码套件，以及如果ClientHello“PSK\u密钥交换\u模式”扩展需要，是否存在服务器“密钥共享”扩展。如果这些值不一致，客户端必须使用“非法参数”警报中止握手。
If the server supplies an "early_data" extension, the client MUST verify that the server's selected_identity is 0. If any other value is returned, the client MUST abort the handshake with an "illegal_parameter" alert.
如果服务器提供“早期_数据”扩展，则客户端必须验证服务器所选的_标识是否为0。如果返回任何其他值，客户端必须使用“非法_参数”警报中止握手。
The "pre_shared_key" extension MUST be the last extension in the ClientHello (this facilitates implementation as described below). Servers MUST check that it is the last extension and otherwise fail the handshake with an "illegal_parameter" alert.
“pre_shared_key”扩展必须是ClientHello中的最后一个扩展（这有助于实现，如下所述）。服务器必须检查它是否是最后一个扩展，否则握手失败并发出“非法参数”警报。
The client's view of the age of a ticket is the time since the receipt of the NewSessionTicket message. Clients MUST NOT attempt to use tickets which have ages greater than the "ticket_lifetime" value which was provided with the ticket. The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the "ticket_age_add" value that was included with the ticket (see Section 4.6.1), modulo 2^32. This addition prevents passive observers from correlating connections unless tickets are reused. Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds. Because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds.
客户对票证有效期的看法是自收到NewSessionTicket消息以来的时间。客户端不得尝试使用票证的有效期大于票证随附的“票证生命周期”值。每个PskIdentity的“模糊票龄”字段包含票龄的模糊版本，该版本通过以毫秒为单位计算票龄，并添加票龄中包含的“票龄添加”值（见第4.6.1节），模数为2^32。此添加可防止被动观察者关联连接，除非票据被重用。请注意，NewSessionTicket消息中的“ticket_life”字段以秒为单位，而“obfuscated_ticket_age”以毫秒为单位。由于票证的生命周期被限制在一周内，32位就足以表示任何可能的年龄，即使以毫秒为单位。
The PSK binder value forms a binding between a PSK and the current handshake, as well as a binding between the handshake in which the PSK was generated (if via a NewSessionTicket message) and the current handshake. Each entry in the binders list is computed as an HMAC over a transcript hash (see Section 4.4.1) containing a partial ClientHello up to and including the PreSharedKeyExtension.identities field. That is, it includes all of the ClientHello but not the binders list itself. The length fields for the message (including the overall length, the length of the extensions block, and the length of the "pre_shared_key" extension) are all set as if binders of the correct lengths were present.
PSK绑定值在PSK和当前握手之间形成绑定，并且在生成PSK的握手（如果通过新闻会话票证消息）和当前握手之间形成绑定。binders列表中的每个条目都作为一个HMAC在包含部分ClientHello的转录本哈希（见第4.4.1节）上进行计算，该部分ClientHello最多包含PreSharedKeyExtension.Identifies字段。也就是说，它包括所有ClientHello，但不包括binders列表本身。消息的长度字段（包括总长度、扩展块的长度和“pre_shared_key”扩展的长度）都设置为存在正确长度的绑定。
The PskBinderEntry is computed in the same way as the Finished message (Section 4.4.4) but with the BaseKey being the binder_key derived via the key schedule from the corresponding PSK which is being offered (see Section 7.1).
PskBinderEntry的计算方法与完成的消息（第4.4.4节）相同，但BaseKey是通过密钥计划从提供的相应PSK派生的绑定密钥（见第7.1节）。
If the handshake includes a HelloRetryRequest, the initial ClientHello and HelloRetryRequest are included in the transcript along with the new ClientHello. For instance, if the client sends ClientHello1, its binder will be computed over:
如果握手包括HelloRetryRequest，则最初的ClientHello和HelloRetryRequest将与新的ClientHello一起包含在转录本中。例如，如果客户端发送ClientHello1，其绑定器将通过以下方式计算：
Transcript-Hash(Truncate(ClientHello1))
转录本散列（截断（ClientHello1））
Where Truncate() removes the binders list from the ClientHello.
其中Truncate（）从ClientHello中删除绑定器列表。
If the server responds with a HelloRetryRequest and the client then sends ClientHello2, its binder will be computed over:
如果服务器响应HelloRetryRequest，然后客户端发送ClientHello2，则其绑定将通过以下方式计算：
Transcript-Hash(ClientHello1, HelloRetryRequest, Truncate(ClientHello2))
转录本哈希（ClientHello1，HelloRetryRequest，Truncate（ClientHello2））
The full ClientHello1/ClientHello2 is included in all other handshake hash computations. Note that in the first flight, Truncate(ClientHello1) is hashed directly, but in the second flight, ClientHello1 is hashed and then reinjected as a "message_hash" message, as described in Section 4.4.1.
完整的ClientHello1/ClientHello2包含在所有其他握手散列计算中。请注意，在第一次飞行中，Truncate（ClientHello1）直接进行散列，但在第二次飞行中，ClientHello1进行散列，然后作为“message_hash”消息重新注入，如第4.4.1节所述。
Clients are permitted to "stream" 0-RTT data until they receive the server's Finished, only then sending the EndOfEarlyData message, followed by the rest of the handshake. In order to avoid deadlocks, when accepting "early_data", servers MUST process the client's ClientHello and then immediately send their flight of messages, rather than waiting for the client's EndOfEarlyData message before sending its ServerHello.
允许客户端“流式传输”0-RTT数据，直到它们接收到服务器的结束，然后才发送EndofarlyData消息，然后是握手的其余部分。为了避免死锁，在接受“早期数据”时，服务器必须先处理客户端的ClientHello，然后立即发送消息，而不是在发送其ServerHello之前等待客户端的EndOfEarlyData消息。
The next two messages from the server, EncryptedExtensions and CertificateRequest, contain information from the server that determines the rest of the handshake. These messages are encrypted with keys derived from the server_handshake_traffic_secret.
接下来来自服务器的两条消息EncryptedExtensions和CertificateRequest包含来自服务器的信息，这些信息决定了握手的其余部分。这些消息使用来自服务器\u握手\u通信\u秘密的密钥进行加密。
In all handshakes, the server MUST send the EncryptedExtensions message immediately after the ServerHello message. This is the first message that is encrypted under keys derived from the server_handshake_traffic_secret.
在所有握手中，服务器必须在ServerHello消息之后立即发送EncryptedExtensions消息。这是第一条使用从服务器\u握手\u通信\u秘密派生的密钥加密的消息。
The EncryptedExtensions message contains extensions that can be protected, i.e., any which are not needed to establish the cryptographic context but which are not associated with individual certificates. The client MUST check EncryptedExtensions for the presence of any forbidden extensions and if any are found MUST abort the handshake with an "illegal_parameter" alert.
EncryptedExtensions消息包含可受保护的扩展，即建立加密上下文不需要但与单个证书无关的任何扩展。客户端必须检查EncryptedExtensions是否存在任何禁止的扩展，如果发现任何扩展，则必须使用“非法_参数”警报中止握手。
Structure of this message:
此消息的结构：
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
extensions: A list of extensions. For more information, see the table in Section 4.2.
扩展：扩展的列表。有关更多信息，请参见第4.2节中的表格。
A server which is authenticating with a certificate MAY optionally request a certificate from the client. This message, if sent, MUST follow EncryptedExtensions.
使用证书进行身份验证的服务器可以选择从客户端请求证书。此消息如果发送，必须在EncryptedExtensions之后。
Structure of this message:
此消息的结构：
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
certificate_request_context: An opaque string which identifies the certificate request and which will be echoed in the client's Certificate message. The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of client CertificateVerify messages). This field SHALL be zero length unless used for the post-handshake authentication exchanges described in Section 4.6.2. When requesting post-handshake authentication, the server SHOULD make the context unpredictable to the client (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the client's private key from pre-computing valid CertificateVerify messages.
certificate_request_context：一个不透明的字符串，用于标识证书请求，并将在客户端的证书消息中回显。证书\u请求\u上下文在此连接范围内必须是唯一的（从而防止重播客户端CertificateVerify消息）。除非用于第4.6.2节所述的握手后认证交换，否则该字段的长度应为零。请求握手后身份验证时，服务器应使客户端无法预测上下文（例如，通过随机生成上下文），以防止临时访问客户端私钥的攻击者预计算有效的CertificateVerify消息。
extensions: A set of extensions describing the parameters of the certificate being requested. The "signature_algorithms" extension MUST be specified, and other extensions may optionally be included if defined for this message. Clients MUST ignore unrecognized extensions.
扩展：描述所请求证书参数的一组扩展。必须指定“signature_algorithms”（签名算法）扩展，如果为此消息定义了其他扩展，则可以选择包括这些扩展。客户端必须忽略无法识别的扩展。
In prior versions of TLS, the CertificateRequest message carried a list of signature algorithms and certificate authorities which the server would accept. In TLS 1.3, the former is expressed by sending the "signature_algorithms" and optionally "signature_algorithms_cert" extensions. The latter is expressed by sending the "certificate_authorities" extension (see Section 4.2.4).
在TLS的早期版本中，CertificateRequest消息包含服务器将接受的签名算法和证书颁发机构的列表。在TLS 1.3中，前者通过发送“签名算法”和可选的“签名算法证书”扩展来表示。后者通过发送“认证机构”扩展来表示（见第4.2.4节）。
Servers which are authenticating with a PSK MUST NOT send the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see Section 4.6.2) provided that the client has sent the "post_handshake_auth" extension (see Section 4.2.6).
使用PSK进行身份验证的服务器不得在主握手中发送CertificateRequest消息，尽管它们可以在握手后身份验证（参见第4.6.2节）中发送该消息，前提是客户端已发送“握手后身份验证”扩展（参见第4.2.6节）。
As discussed in Section 2, TLS generally uses a common set of messages for authentication, key confirmation, and handshake integrity: Certificate, CertificateVerify, and Finished. (The PSK binders also perform key confirmation, in a similar fashion.) These three messages are always sent as the last messages in their handshake flight. The Certificate and CertificateVerify messages are only sent under certain circumstances, as defined below. The Finished message is always sent as part of the Authentication Block. These messages are encrypted under keys derived from the [sender]_handshake_traffic_secret.
如第2节所述，TLS通常使用一组通用消息来进行身份验证、密钥确认和握手完整性：Certificate、CertificateVerify和Finished。（PSK绑定器也以类似的方式执行密钥确认。）这三条消息始终作为握手飞行中的最后一条消息发送。Certificate和CertificateVerify消息仅在特定情况下发送，定义如下。完成的消息始终作为身份验证块的一部分发送。这些消息使用从[发送方]\u握手\u通信量\u秘密派生的密钥进行加密。
The computations for the Authentication messages all uniformly take the following inputs:
验证消息的计算都统一采用以下输入：
- The certificate and signing key to be used.
- 要使用的证书和签名密钥。
- A Handshake Context consisting of the set of messages to be included in the transcript hash.
- 一种握手上下文，由要包含在转录本哈希中的一组消息组成。
- A Base Key to be used to compute a MAC key.
- 用于计算MAC密钥的基本密钥。
Based on these inputs, the messages then contain:
根据这些输入，消息将包含：
Certificate: The certificate to be used for authentication, and any supporting certificates in the chain. Note that certificate-based client authentication is not available in PSK handshake flows (including 0-RTT).
证书：用于身份验证的证书，以及链中的任何支持证书。请注意，基于证书的客户端身份验证在PSK握手流（包括0-RTT）中不可用。
CertificateVerify: A signature over the value Transcript-Hash(Handshake Context, Certificate).
CertificateVerify：值转录本哈希（握手上下文、证书）上的签名。
Finished: A MAC over the value Transcript-Hash(Handshake Context, Certificate, CertificateVerify) using a MAC key derived from the Base Key.
已完成：使用从基密钥派生的MAC密钥对值转录本哈希（握手上下文、证书、CertificateVerify）进行MAC覆盖。
The following table defines the Handshake Context and MAC Base Key for each scenario:
下表定义了每个场景的握手上下文和MAC基本密钥：
+-----------+-------------------------+-----------------------------+
| Mode | Handshake Context | Base Key |
+-----------+-------------------------+-----------------------------+
| Server | ClientHello ... later | server_handshake_traffic_ |
| | of EncryptedExtensions/ | secret |
| | CertificateRequest | |
| | | |
| Client | ClientHello ... later | client_handshake_traffic_ |
| | of server | secret |
| | Finished/EndOfEarlyData | |
| | | |
| Post- | ClientHello ... client | client_application_traffic_ |
| Handshake | Finished + | secret_N |
| | CertificateRequest | |
+-----------+-------------------------+-----------------------------+
+-----------+-------------------------+-----------------------------+
| Mode | Handshake Context | Base Key |
+-----------+-------------------------+-----------------------------+
| Server | ClientHello ... later | server_handshake_traffic_ |
| | of EncryptedExtensions/ | secret |
| | CertificateRequest | |
| | | |
| Client | ClientHello ... later | client_handshake_traffic_ |
| | of server | secret |
| | Finished/EndOfEarlyData | |
| | | |
| Post- | ClientHello ... client | client_application_traffic_ |
| Handshake | Finished + | secret_N |
| | CertificateRequest | |
+-----------+-------------------------+-----------------------------+
Many of the cryptographic computations in TLS make use of a transcript hash. This value is computed by hashing the concatenation of each included handshake message, including the handshake message header carrying the handshake message type and length fields, but not including record layer headers. I.e.,
TLS中的许多加密计算都使用转录哈希。该值是通过对每个包含的握手消息（包括承载握手消息类型和长度字段的握手消息头，但不包括记录层头）的串联进行散列来计算的。即。，
Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn)
Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn)
As an exception to this general rule, when the server responds to a ClientHello with a HelloRetryRequest, the value of ClientHello1 is replaced with a special synthetic handshake message of handshake type "message_hash" containing Hash(ClientHello1). I.e.,
作为此一般规则的例外，当服务器使用HelloRetryRequest响应ClientHello时，ClientHello1的值将替换为包含哈希（ClientHello1）的握手类型为“message_hash”的特殊合成握手消息。即。，
Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash || /* Handshake type */
00 00 Hash.length || /* Handshake message length (bytes) */
Hash(ClientHello1) || /* Hash of ClientHello1 */
HelloRetryRequest || ... || Mn)
Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
Hash(message_hash || /* Handshake type */
00 00 Hash.length || /* Handshake message length (bytes) */
Hash(ClientHello1) || /* Hash of ClientHello1 */
HelloRetryRequest || ... || Mn)
The reason for this construction is to allow the server to do a stateless HelloRetryRequest by storing just the hash of ClientHello1 in the cookie, rather than requiring it to export the entire intermediate hash state (see Section 4.2.2).
这种构造的原因是允许服务器通过在cookie中只存储ClientHello1的哈希来执行无状态HelloRetryRequest，而不是要求它导出整个中间哈希状态（参见第4.2.2节）。
For concreteness, the transcript hash is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, server CertificateRequest, server Certificate, server CertificateVerify, server Finished, EndOfEarlyData, client Certificate, client CertificateVerify, client Finished.
为具体起见，抄本哈希始终取自以下握手消息序列，从第一个ClientHello开始，仅包括已发送的消息：ClientHello、HelloRetryRequest、ClientHello、ServerHello、EncryptedExtensions、server CertificateRequest、server CertificateVerify、，服务器完成，内部数据，客户端证书，客户端证书验证，客户端完成。
In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash. Note, however, that subsequent post-handshake authentications do not include each other, just the messages through the end of the main handshake.
通常，实现可以通过基于协商的散列保留正在运行的转录本散列值来实现转录本。但是，请注意，后续的握手后身份验证并不相互包括，只包括通过主握手结束的消息。
This message conveys the endpoint's certificate chain to the peer.
此消息将端点的证书链传递给对等方。
The server MUST send a Certificate message whenever the agreed-upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except PSK).
每当约定的密钥交换方法使用证书进行身份验证时，服务器必须发送证书消息（这包括本文档中定义的除PSK之外的所有密钥交换方法）。
The client MUST send a Certificate message if and only if the server has requested client authentication via a CertificateRequest message (Section 4.3.2). If the server requests client authentication but no suitable certificate is available, the client MUST send a Certificate message containing no certificates (i.e., with the "certificate_list" field having length 0). A Finished message MUST be sent regardless of whether the Certificate message is empty.
当且仅当服务器通过CertificateRequest消息请求客户端身份验证时，客户端必须发送证书消息（第4.3.2节）。如果服务器请求客户端身份验证，但没有合适的证书可用，则客户端必须发送不包含证书的证书消息（即，“证书列表”字段的长度为0）。无论证书消息是否为空，都必须发送完成的消息。
Structure of this message:
此消息的结构：
enum {
X509(0),
RawPublicKey(2),
(255)
} CertificateType;
enum {
X509(0),
RawPublicKey(2),
(255)
} CertificateType;
struct {
select (certificate_type) {
case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
struct {
select (certificate_type) {
case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
certificate_request_context: If this message is in response to a CertificateRequest, the value of certificate_request_context in that message. Otherwise (in the case of server authentication), this field SHALL be zero length.
证书请求上下文：如果此消息响应证书请求，则该消息中证书请求上下文的值。否则（在服务器身份验证的情况下），此字段的长度应为零。
certificate_list: A sequence (chain) of CertificateEntry structures, each containing a single certificate and set of extensions.
证书列表：证书尝试结构的序列（链），每个结构包含一个证书和一组扩展。
extensions: A set of extension values for the CertificateEntry. The "Extension" format is defined in Section 4.2. Valid extensions for server certificates at present include the OCSP Status extension [RFC6066] and the SignedCertificateTimestamp extension [RFC6962]; future extensions may be defined for this message as well. Extensions in the Certificate message from the server MUST correspond to ones from the ClientHello message. Extensions in the Certificate message from the client MUST correspond to extensions in the CertificateRequest message from the server. If an extension applies to the entire chain, it SHOULD be included in the first CertificateEntry.
扩展：CertificateEntry的一组扩展值。第4.2节定义了“扩展”格式。目前服务器证书的有效扩展包括OCSP状态扩展[RFC6066]和SignedCertificateTimestamp扩展[RFC6962]；也可以为此消息定义将来的扩展。来自服务器的证书消息中的扩展必须与ClientHello消息中的扩展相对应。来自客户端的证书消息中的扩展必须对应于来自服务器的CertificateRequest消息中的扩展。如果扩展适用于整个链，则应将其包括在第一个证书尝试中。
If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not negotiated in EncryptedExtensions, or the X.509 certificate type was negotiated, then each CertificateEntry contains a DER-encoded X.509 certificate. The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify the one immediately preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates.
如果相应的证书类型扩展（“服务器证书类型”或“客户端证书类型”）未在EncryptedExtensions中协商，或者X.509证书类型已协商，则每个证书尝试都包含一个DER编码的X.509证书。发件人的证书必须位于列表中的第一个CertificateEntry中。以下各证书应直接证明其前一个证书。由于证书验证要求独立分发信任锚，因此可以从链中省略指定信任锚的证书，前提是已知受支持的对等方拥有任何省略的证书。
Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however, some implementations allowed some flexibility. Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly. For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first.
注：在TLS 1.3之前，“证书列表”订购要求每个证书证明其前一个证书；然而，一些实现允许一些灵活性。服务器有时会出于过渡目的发送当前和不推荐的中间版本，而其他服务器只是配置不正确，但这些情况仍然可以正确验证。为了实现最大的兼容性，所有实现都应该准备好处理来自任何TLS版本的潜在无关证书和任意顺序，但必须首先处理的终端实体证书除外。
If the RawPublicKey certificate type was negotiated, then the certificate_list MUST contain no more than one CertificateEntry, which contains an ASN1_subjectPublicKeyInfo value as defined in [RFC7250], Section 3.
如果协商了RawPublicKey证书类型，则证书列表必须包含不超过一个CertificateEntry，其中包含[RFC7250]第3节中定义的ASN1\U subjectPublicKeyInfo值。
The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3.
OpenPGP证书类型[RFC6091]不得与TLS 1.3一起使用。
The server's certificate_list MUST always be non-empty. A client will send an empty certificate_list if it does not have an appropriate certificate to send in response to the server's authentication request.
服务器的证书列表必须始终为非空。如果客户端没有响应服务器的身份验证请求而发送的适当证书，则客户端将发送空证书列表。
[RFC6066] and [RFC6961] provide extensions to negotiate the server sending OCSP responses to the client. In TLS 1.2 and below, the server replies with an empty extension to indicate negotiation of this extension and the OCSP information is carried in a CertificateStatus message. In TLS 1.3, the server's OCSP information is carried in an extension in the CertificateEntry containing the associated certificate. Specifically, the body of the "status_request" extension from the server MUST be a CertificateStatus structure as defined in [RFC6066], which is interpreted as defined in [RFC6960].
[RFC6066]和[RFC6961]提供扩展来协商服务器向客户端发送OCSP响应。在TLS 1.2及以下版本中，服务器使用空扩展名进行响应，以指示此扩展名的协商，并且OCSP信息包含在CertificateStatus消息中。在TLS 1.3中，服务器的OCSP信息包含在包含相关证书的CertificateEntry中的扩展中。具体而言，来自服务器的“status_request”扩展的主体必须是[RFC6066]中定义的CertificateStatus结构，其解释为[RFC6960]中定义的结构。
Note: The status_request_v2 extension [RFC6961] is deprecated. TLS 1.3 servers MUST NOT act upon its presence or information in it when processing ClientHello messages; in particular, they MUST NOT send the status_request_v2 extension in the EncryptedExtensions, CertificateRequest, or Certificate messages. TLS 1.3 servers MUST be able to process ClientHello messages that include it, as it MAY be sent by clients that wish to use it in earlier protocol versions.
注意：状态请求v2扩展[RFC6961]已弃用。TLS 1.3服务器在处理ClientHello消息时，不得根据其存在或其中的信息行事；特别是，他们不得在EncryptedExtensions、CertificateRequest或Certificate消息中发送状态_请求_v2扩展。TLS 1.3服务器必须能够处理包含它的ClientHello消息，因为它可能由希望在早期协议版本中使用它的客户端发送。
A server MAY request that a client present an OCSP response with its certificate by sending an empty "status_request" extension in its CertificateRequest message. If the client opts to send an OCSP response, the body of its "status_request" extension MUST be a CertificateStatus structure as defined in [RFC6066].
服务器可以通过在其CertificateRequest消息中发送一个空的“status_request”扩展名，请求客户机提供OCSP响应及其证书。如果客户端选择发送OCSP响应，则其“状态请求”扩展的主体必须是[RFC6066]中定义的CertificateStatus结构。
Similarly, [RFC6962] provides a mechanism for a server to send a Signed Certificate Timestamp (SCT) as an extension in the ServerHello in TLS 1.2 and below. In TLS 1.3, the server's SCT information is carried in an extension in the CertificateEntry.
类似地，[RFC6962]为服务器提供了一种机制，以发送签名证书时间戳（SCT）作为TLS 1.2及以下版本中ServerHello的扩展。在TLS 1.3中，服务器的SCT信息在CertificateEntry的扩展中携带。
The following rules apply to the certificates sent by the server:
以下规则适用于服务器发送的证书：
- The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated otherwise (e.g., [RFC7250]).
- 证书类型必须为X.509v3[RFC5280]，除非另有明确协商（例如[RFC7250]）。
- The server's end-entity certificate's public key (and associated restrictions) MUST be compatible with the selected authentication algorithm from the client's "signature_algorithms" extension (currently RSA, ECDSA, or EdDSA).
- 服务器的终端实体证书的公钥（和相关限制）必须与从客户端的“签名算法”扩展（当前为RSA、ECDSA或EdDSA）中选择的身份验证算法兼容。
- The certificate MUST allow the key to be used for signing (i.e., the digitalSignature bit MUST be set if the Key Usage extension is present) with a signature scheme indicated in the client's "signature_algorithms"/"signature_algorithms_cert" extensions (see Section 4.2.3).
- 证书必须允许使用客户的“签名算法”/“签名算法证书”扩展（见第4.2.3节）中指示的签名方案对密钥进行签名（即，如果存在密钥使用扩展，则必须设置数字签名位）。
- The "server_name" [RFC6066] and "certificate_authorities" extensions are used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable.
- “服务器名称”[RFC6066]和“证书颁发机构”扩展用于指导证书选择。由于服务器可能需要“服务器名称”扩展，因此客户端应在适用时发送此扩展。
All certificates provided by the server MUST be signed by a signature algorithm advertised by the client if it is able to provide such a chain (see Section 4.2.3). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm.
如果服务器能够提供这样的链，则服务器提供的所有证书必须由客户端公布的签名算法签名（见第4.2.3节）。自签名证书或预期为信任锚的证书不会作为链的一部分进行验证，因此可以使用任何算法进行签名。
If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain SHOULD NOT use the deprecated SHA-1 hash algorithm in general, but MAY do so if the client's advertisement permits it, and MUST NOT do so otherwise.
如果服务器无法生成仅通过指定的受支持算法签名的证书链，则应通过向客户端发送其选择的证书链来继续握手，该证书链可能包括客户端不支持的已知算法。此回退链一般不应使用不推荐使用的SHA-1哈希算法，但如果客户机的公告允许，则可以这样做，否则不得这样做。
If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort the handshake with an appropriate certificate-related alert (by default, "unsupported_certificate"; see Section 6.2 for more information).
如果客户端无法使用提供的证书构建可接受的链并决定中止握手，则必须使用适当的证书相关警报中止握手（默认情况下，“不支持的_证书”；有关详细信息，请参阅第6.2节）。
If the server has multiple certificates, it chooses one of them based on the above-mentioned criteria (in addition to other criteria, such as transport-layer endpoint, local configuration, and preferences).
如果服务器有多个证书，它将根据上述标准（以及其他标准，如传输层端点、本地配置和首选项）选择其中一个证书。
The following rules apply to certificates sent by the client:
以下规则适用于客户端发送的证书：
- The certificate type MUST be X.509v3 [RFC5280], unless explicitly negotiated otherwise (e.g., [RFC7250]).
- 证书类型必须为X.509v3[RFC5280]，除非另有明确协商（例如[RFC7250]）。
- If the "certificate_authorities" extension in the CertificateRequest message was present, at least one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs.
- 如果CertificateRequest消息中存在“certificate_Authority”扩展，则证书链中至少有一个证书应由列出的CA之一颁发。
- The certificates MUST be signed using an acceptable signature algorithm, as described in Section 4.3.2. Note that this relaxes the constraints on certificate-signing algorithms found in prior versions of TLS.
- 证书必须使用可接受的签名算法进行签名，如第4.3.2节所述。请注意，这放松了TLS早期版本中对证书签名算法的限制。
- If the CertificateRequest message contained a non-empty "oid_filters" extension, the end-entity certificate MUST match the extension OIDs that are recognized by the client, as described in Section 4.2.5.
- 如果CertificateRequest消息包含非空的“oid_filters”扩展，则终端实体证书必须与客户端识别的扩展oid匹配，如第4.2.5节所述。
In general, detailed certificate validation procedures are out of scope for TLS (see [RFC5280]). This section provides TLS-specific requirements.
一般来说，TLS不适用于详细的证书验证程序（请参见[RFC5280]）。本节提供了TLS的具体要求。
If the server supplies an empty Certificate message, the client MUST abort the handshake with a "decode_error" alert.
如果服务器提供空证书消息，则客户端必须中止握手并发出“解码错误”警报。
If the client does not send any certificates (i.e., it sends an empty Certificate message), the server MAY at its discretion either continue the handshake without client authentication or abort the handshake with a "certificate_required" alert. Also, if some aspect of the certificate chain was unacceptable (e.g., it was not signed by a known, trusted CA), the server MAY at its discretion either continue the handshake (considering the client unauthenticated) or abort the handshake.
如果客户端不发送任何证书（即，它发送一条空证书消息），服务器可以自行决定在没有客户端身份验证的情况下继续握手，或者在发出“需要证书”警报的情况下中止握手。此外，如果证书链的某些方面不可接受（例如，它没有由已知的、受信任的CA签名），服务器可以自行决定继续握手（考虑到客户端未经身份验证）或中止握手。
Any endpoint receiving any certificate which it would need to validate using any signature algorithm using an MD5 hash MUST abort the handshake with a "bad_certificate" alert. SHA-1 is deprecated, and it is RECOMMENDED that any endpoint receiving any certificate which it would need to validate using any signature algorithm using a SHA-1 hash abort the handshake with a "bad_certificate" alert. For clarity, this means that endpoints can accept these algorithms for certificates that are self-signed or are trust anchors.
接收到需要使用MD5哈希的任何签名算法验证的任何证书的任何端点都必须使用“bad_certificate”警报中止握手。不推荐使用SHA-1，建议接收证书的任何端点使用SHA-1哈希使用任何签名算法进行验证，并使用“bad_证书”警报中止握手。为清楚起见，这意味着端点可以接受这些算法，用于自签名或信任锚的证书。
All endpoints are RECOMMENDED to transition to SHA-256 or better as soon as possible to maintain interoperability with implementations currently in the process of phasing out SHA-1 support.
建议所有端点尽快过渡到SHA-256或更高版本，以保持与目前正在逐步取消SHA-1支持的实现的互操作性。
Note that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with an ECDSA key).
请注意，包含一个签名算法密钥的证书可以使用不同的签名算法（例如，使用ECDSA密钥签名的RSA密钥）进行签名。
This message is used to provide explicit proof that an endpoint possesses the private key corresponding to its certificate. The CertificateVerify message also provides integrity for the handshake up to this point. Servers MUST send this message when authenticating via a certificate. Clients MUST send this message whenever authenticating via a certificate (i.e., when the Certificate message is non-empty). When sent, this message MUST appear immediately after the Certificate message and immediately prior to the Finished message.
此消息用于提供端点拥有与其证书对应的私钥的明确证明。到目前为止，CertificateVerify消息还提供了握手的完整性。服务器在通过证书进行身份验证时必须发送此消息。每当通过证书进行身份验证时（即，当证书消息为非空时），客户端必须发送此消息。发送时，此消息必须紧跟在证书消息之后，紧跟在完成的消息之前。
Structure of this message:
此消息的结构：
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
The algorithm field specifies the signature algorithm used (see Section 4.2.3 for the definition of this type). The signature is a digital signature using that algorithm. The content that is covered under the signature is the hash output as described in Section 4.4.1, namely:
algorithm（算法）字段指定使用的签名算法（该类型的定义见第4.2.3节）。签名是使用该算法的数字签名。签名所涵盖的内容是第4.4.1节所述的散列输出，即：
Transcript-Hash(Handshake Context, Certificate)
成绩单哈希（握手上下文、证书）
The digital signature is then computed over the concatenation of:
然后，通过以下连接计算数字签名：
- A string that consists of octet 32 (0x20) repeated 64 times
- 由重复64次的八位字节32（0x20）组成的字符串
- The context string
- 上下文字符串
- A single 0 byte which serves as the separator
- 用作分隔符的单个0字节
- The content to be signed
- 要签名的内容
This structure is intended to prevent an attack on previous versions of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen 32-byte prefix (ClientHello.random). The initial 64-byte pad clears that prefix along with the server-controlled ServerHello.random.
此结构旨在防止对以前版本的TLS的攻击，其中ServerKeyExchange格式意味着攻击者可以获得具有选定32字节前缀（ClientHello.random）的消息签名。初始64字节的pad将清除该前缀以及服务器控制的ServerHello.random。
The context string for a server signature is "TLS 1.3, server CertificateVerify". The context string for a client signature is "TLS 1.3, client CertificateVerify". It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks.
服务器签名的上下文字符串是“TLS 1.3，服务器证书化”。客户端签名的上下文字符串是“TLS 1.3，客户端证书验证”。它用于在不同上下文中生成的签名之间提供分离，有助于防止潜在的跨协议攻击。
For example, if the transcript hash was 32 bytes of 01 (this length would make sense for SHA-256), the content covered by the digital signature for a server CertificateVerify would be:
例如，如果转录本哈希为32字节01（该长度对SHA-256有意义），则服务器CertificateVerify的数字签名所涵盖的内容将是：
2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020
544c5320312e332c207365727665722043657274696669636174655665726966
79
00
0101010101010101010101010101010101010101010101010101010101010101
2020202020202020202020202020202020202020202020202020202020202020
2020202020202020202020202020202020202020202020202020202020202020
544c5320312e332c207365727665722043657274696669636174655665726966
79
00
0101010101010101010101010101010101010101010101010101010101010101
On the sender side, the process for computing the signature field of the CertificateVerify message takes as input:
在发送方，计算CertificateVerify消息的签名字段的过程将以下内容作为输入：
- The content covered by the digital signature
- 数字签名所涵盖的内容
- The private signing key corresponding to the certificate sent in the previous message
- 与上一条消息中发送的证书相对应的私有签名密钥
If the CertificateVerify message is sent by a server, the signature algorithm MUST be one offered in the client's "signature_algorithms" extension unless no valid certificate chain can be produced without unsupported algorithms (see Section 4.2.3).
如果CertificateVerify消息是由服务器发送的，则签名算法必须是客户端的“签名算法”扩展中提供的算法，除非没有不受支持的算法无法生成有效的证书链（见第4.2.3节）。
If sent by a client, the signature algorithm used in the signature MUST be one of those present in the supported_signature_algorithms field of the "signature_algorithms" extension in the CertificateRequest message.
如果由客户端发送，则签名中使用的签名算法必须是CertificateRequest消息中“signature_algorithms”（签名算法）扩展的supported_signature_algorithms（受支持的_签名算法）字段中的算法之一。
In addition, the signature algorithm MUST be compatible with the key in the sender's end-entity certificate. RSA signatures MUST use an RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5 algorithms appear in "signature_algorithms". The SHA-1 algorithm MUST NOT be used in any signatures of CertificateVerify messages.
此外，签名算法必须与发送方的最终实体证书中的密钥兼容。RSA签名必须使用RSASSA-PSS算法，无论RSASSA-PKCS1-v1_5算法是否出现在“签名_算法”中。SHA-1算法不得用于CertificateVerify消息的任何签名。
All SHA-1 signature algorithms in this specification are defined solely for use in legacy certificates and are not valid for CertificateVerify signatures.
本规范中的所有SHA-1签名算法仅定义用于遗留证书，对CertificateVerify签名无效。
The receiver of a CertificateVerify message MUST verify the signature field. The verification process takes as input:
CertificateVerify消息的接收者必须验证签名字段。验证过程以以下内容作为输入：
- The content covered by the digital signature
- 数字签名所涵盖的内容
- The public key contained in the end-entity certificate found in the associated Certificate message
- 在关联的证书消息中找到的最终实体证书中包含的公钥
- The digital signature received in the signature field of the CertificateVerify message
- 在CertificateVerify消息的签名字段中接收的数字签名
If the verification fails, the receiver MUST terminate the handshake with a "decrypt_error" alert.
如果验证失败，接收方必须发出“解密错误”警报终止握手。
The Finished message is the final message in the Authentication Block. It is essential for providing authentication of the handshake and of the computed keys.
完成的消息是身份验证块中的最后一条消息。它对于提供握手和计算密钥的身份验证至关重要。
Recipients of Finished messages MUST verify that the contents are correct and if incorrect MUST terminate the connection with a "decrypt_error" alert.
完成邮件的收件人必须验证内容是否正确，如果内容不正确，则必须发出“解密错误”警报终止连接。
Once a side has sent its Finished message and has received and validated the Finished message from its peer, it may begin to send and receive Application Data over the connection. There are two settings in which it is permitted to send data prior to receiving the peer's Finished:
一旦一方发送了完成的消息，并从其对等方接收并验证了完成的消息，它就可以开始通过连接发送和接收应用程序数据。有两种设置允许在接收对等方的完成数据之前发送数据：
1. Clients sending 0-RTT data as described in Section 4.2.10.
1. 客户端发送第4.2.10节所述的0-RTT数据。
2. Servers MAY send data after sending their first flight, but because the handshake is not yet complete, they have no assurance of either the peer's identity or its liveness (i.e., the ClientHello might have been replayed).
2. 服务器可以在发送第一次航班后发送数据，但由于握手尚未完成，因此无法保证对等方的身份或活动性（即，ClientHello可能已被重播）。
The key used to compute the Finished message is computed from the Base Key defined in Section 4.4 using HKDF (see Section 7.1). Specifically:
用于计算完成消息的密钥是使用HKDF从第4.4节中定义的基本密钥计算的（参见第7.1节）。明确地：
finished_key = HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)
finished_key=HKDF展开标签（BaseKey，“finished”，“”，Hash.length）
Structure of this message:
此消息的结构：
struct {
opaque verify_data[Hash.length];
} Finished;
struct {
opaque verify_data[Hash.length];
} Finished;
The verify_data value is computed as follows:
验证_数据值的计算如下：
verify_data = HMAC(finished_key, Transcript-Hash(Handshake Context, Certificate*, CertificateVerify*))
验证\u data=HMAC（完成的\u密钥、成绩单哈希（握手上下文、证书*、证书验证*）
* Only included if present.
* 仅在存在时才包括在内。
HMAC [RFC2104] uses the Hash algorithm for the handshake. As noted above, the HMAC input can generally be implemented by a running hash, i.e., just the handshake hash at this point.
HMAC[RFC2104]使用哈希算法进行握手。如上所述，HMAC输入通常可以通过运行散列来实现，即，此时仅通过握手散列。
In previous versions of TLS, the verify_data was always 12 octets long. In TLS 1.3, it is the size of the HMAC output for the Hash used for the handshake.
在以前版本的TLS中，验证_数据的长度始终为12个八位字节。在TLS1.3中，它是用于握手的哈希的HMAC输出的大小。
Note: Alerts and any other non-handshake record types are not handshake messages and are not included in the hash computations.
注意：警报和任何其他非握手记录类型不是握手消息，也不包括在哈希计算中。
Any records following a Finished message MUST be encrypted under the appropriate application traffic key as described in Section 7.2. In particular, this includes any alerts sent by the server in response to client Certificate and CertificateVerify messages.
完成消息后的任何记录必须按照第7.2节所述的适当应用程序通信密钥进行加密。特别是，这包括服务器为响应客户端证书和CertificateVerify消息而发送的任何警报。
struct {} EndOfEarlyData;
struct {} EndOfEarlyData;
If the server sent an "early_data" extension in EncryptedExtensions, the client MUST send an EndOfEarlyData message after receiving the server Finished. If the server does not send an "early_data" extension in EncryptedExtensions, then the client MUST NOT send an EndOfEarlyData message. This message indicates that all 0-RTT application_data messages, if any, have been transmitted and that the
如果服务器在EncryptedExtensions中发送了“early_data”扩展，则客户端必须在接收到服务器完成后发送EndOfEarlyData消息。如果服务器未在EncryptedExtensions中发送“early_data”扩展，则客户端不得发送EndofarlyData消息。此消息表示所有0-RTT应用程序_数据消息（如有）已传输，并且
following records are protected under handshake traffic keys. Servers MUST NOT send this message, and clients receiving it MUST terminate the connection with an "unexpected_message" alert. This message is encrypted under keys derived from the client_early_traffic_secret.
以下记录受握手通信密钥保护。服务器不得发送此消息，接收此消息的客户端必须使用“意外消息”警报终止连接。此消息使用来自客户端\u早期\u流量\u机密的密钥进行加密。
TLS also allows other messages to be sent after the main handshake. These messages use a handshake content type and are encrypted under the appropriate application traffic key.
TLS还允许在主握手后发送其他消息。这些消息使用握手内容类型，并在适当的应用程序通信密钥下进行加密。
At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message. This message creates a unique association between the ticket value and a secret PSK derived from the resumption master secret (see Section 7).
在服务器收到客户端完成消息后的任何时候，它都可以发送一条NewSessionTicket消息。此消息在票证值和从恢复主密钥派生的密钥PSK之间创建唯一关联（参见第7节）。
The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello (Section 4.2.11). Servers MAY send multiple tickets on a single connection, either immediately after each other or after specific events (see Appendix C.4). For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state. Multiple tickets are useful for clients for a variety of purposes, including:
客户可以通过在其ClientHello（第4.2.11节）中包含“pre_shared_key”扩展中的票证值，将此PSK用于未来的握手。服务器可以在单个连接上发送多个票证，可以是在相互连接后立即发送，也可以是在特定事件后发送（请参见附录C.4）。例如，服务器可能在握手后身份验证之后发送一个新票证，以便封装额外的客户端身份验证状态。多个票证对于客户端有多种用途，包括：
- Opening multiple parallel HTTP connections.
- 打开多个并行HTTP连接。
- Performing connection racing across interfaces and address families via (for example) Happy Eyeballs [RFC8305] or related techniques.
- 通过（例如）快乐眼球[RFC8305]或相关技术跨接口和地址族执行连接竞速。
Any ticket MUST only be resumed with a cipher suite that has the same KDF hash algorithm as that used to establish the original connection.
任何票证都必须使用与用于建立原始连接的KDF哈希算法相同的密码套件恢复。
Clients MUST only resume if the new SNI value is valid for the server certificate presented in the original session and SHOULD only resume if the SNI value matches the one used in the original session. The latter is a performance optimization: normally, there is no reason to expect that different servers covered by a single certificate would be able to accept each other's tickets; hence, attempting resumption in that case would waste a single-use ticket. If such an indication is provided (externally or by any other means), clients MAY resume with a different SNI value.
只有当新SNI值对原始会话中提供的服务器证书有效时，客户端才能恢复，并且只有当SNI值与原始会话中使用的值匹配时，客户端才能恢复。后者是一种性能优化：通常，没有理由期望单个证书覆盖的不同服务器能够接受彼此的票据；因此，在这种情况下尝试恢复将浪费一张一次性票据。如果提供了此类指示（外部或通过任何其他方式），客户可以使用不同的SNI值恢复。
On resumption, if reporting an SNI value to the calling application, implementations MUST use the value sent in the resumption ClientHello rather than the value sent in the previous session. Note that if a server implementation declines all PSK identities with different SNI values, these two values are always the same.
在恢复时，如果向调用应用程序报告SNI值，则实现必须使用在恢复ClientHello中发送的值，而不是在上一个会话中发送的值。请注意，如果服务器实现拒绝具有不同SNI值的所有PSK标识，则这两个值始终相同。
Note: Although the resumption master secret depends on the client's second flight, a server which does not request client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example.
注意：尽管恢复主密钥取决于客户端的第二次飞行，但不请求客户端身份验证的服务器可以独立计算剩余的成绩单，然后在发送完后立即发送NewSessionTicket，而不是等待客户端完成。例如，在客户机预期并行打开多个TLS连接的情况下，这可能是合适的，并且可以从减少的恢复握手开销中获益。
struct {
uint32 ticket_lifetime;
uint32 ticket_age_add;
opaque ticket_nonce<0..255>;
opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>;
} NewSessionTicket;
struct {
uint32 ticket_lifetime;
uint32 ticket_age_add;
opaque ticket_nonce<0..255>;
opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>;
} NewSessionTicket;
ticket_lifetime: Indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order from the time of ticket issuance. Servers MUST NOT use any value greater than 604800 seconds (7 days). The value of zero indicates that the ticket should be discarded immediately. Clients MUST NOT cache tickets for longer than 7 days, regardless of the ticket_lifetime, and MAY delete tickets earlier based on local policy. A server MAY treat a ticket as valid for a shorter period of time than what is stated in the ticket_lifetime.
票证生命周期：从票证发行时起，以32位无符号整数（网络字节顺序）表示以秒为单位的生命周期。服务器不得使用任何大于604800秒（7天）的值。值为零表示应立即丢弃票据。客户端缓存票据的时间不得超过7天，无论票据的生命周期如何，并且可以根据本地策略提前删除票据。服务器可以将票证视为有效期短于票证生命周期中规定的时间。
ticket_age_add: A securely generated, random 32-bit value that is used to obscure the age of the ticket that the client includes in the "pre_shared_key" extension. The client-side ticket age is added to this value modulo 2^32 to obtain the value that is transmitted by the client. The server MUST generate a fresh value for each ticket it sends.
ticket_age_add：一个安全生成的随机32位值，用于隐藏客户端包含在“pre_shared_key”扩展中的ticket的年龄。客户端票证期限将以2^32的模加到此值，以获得客户端传输的值。服务器必须为其发送的每个票证生成一个新值。
ticket_nonce: A per-ticket value that is unique across all tickets issued on this connection.
票证当前：在此连接上发布的所有票证中唯一的每个票证值。
ticket: The value of the ticket to be used as the PSK identity. The ticket itself is an opaque label. It MAY be either a database lookup key or a self-encrypted and self-authenticated value.
票证：用作PSK标识的票证的值。票本身是一个不透明的标签。它可以是数据库查找密钥，也可以是自加密和自验证的值。
extensions: A set of extension values for the ticket. The "Extension" format is defined in Section 4.2. Clients MUST ignore unrecognized extensions.
扩展：票证的一组扩展值。第4.2节定义了“扩展”格式。客户端必须忽略无法识别的扩展。
The sole extension currently defined for NewSessionTicket is "early_data", indicating that the ticket may be used to send 0-RTT data (Section 4.2.10). It contains the following value:
当前为NewSessionTicket定义的唯一扩展名是“early_data”，表示该ticket可用于发送0-RTT数据（第4.2.10节）。它包含以下值：
max_early_data_size: The maximum amount of 0-RTT data that the client is allowed to send when using this ticket, in bytes. Only Application Data payload (i.e., plaintext but not padding or the inner content type byte) is counted. A server receiving more than max_early_data_size bytes of 0-RTT data SHOULD terminate the connection with an "unexpected_message" alert. Note that servers that reject early data due to lack of cryptographic material will be unable to differentiate padding from content, so clients SHOULD NOT depend on being able to send large quantities of padding in early data records.
max_early_data_size：使用此票证时允许客户端发送的最大0-RTT数据量，以字节为单位。仅计算应用程序数据有效负载（即，纯文本，但不计算填充或内部内容类型字节）。如果服务器接收的0-RTT数据超过max_early_data_size字节，则应使用“意外消息”警报终止连接。请注意，由于缺少加密材料而拒绝早期数据的服务器将无法区分填充和内容，因此客户端不应依赖于能够在早期数据记录中发送大量填充。
The PSK associated with the ticket is computed as:
与票据相关的PSK计算如下：
HKDF-Expand-Label(resumption_master_secret, "resumption", ticket_nonce, Hash.length)
HKDF扩展标签（恢复主密钥，“恢复”，票证当前，散列长度）
Because the ticket_nonce value is distinct for each NewSessionTicket message, a different PSK will be derived for each ticket.
由于每个NewSessionTicket消息的票证当前值不同，因此将为每个票证导出不同的PSK。
Note that in principle it is possible to continue issuing new tickets which indefinitely extend the lifetime of the keying material originally derived from an initial non-PSK handshake (which was most likely tied to the peer's certificate). It is RECOMMENDED that implementations place limits on the total lifetime of such keying material; these limits should take into account the lifetime of the peer's certificate, the likelihood of intervening revocation, and the time since the peer's online CertificateVerify signature.
请注意，原则上，可以继续发行新票据，无限期延长最初源自初始非PSK握手（很可能与对等方的证书相关）的密钥材料的使用寿命。建议实施对此类键控材料的总寿命进行限制；这些限制应考虑对等方证书的生命周期、介入撤销的可能性以及自对等方在线CertificateVerify签名以来的时间。
When the client has sent the "post_handshake_auth" extension (see Section 4.2.6), a server MAY request client authentication at any time after the handshake has completed by sending a CertificateRequest message. The client MUST respond with the appropriate Authentication messages (see Section 4.4). If the client chooses to authenticate, it MUST send Certificate, CertificateVerify,
当客户端发送了“post_handshake_auth”扩展（参见第4.2.6节）时，服务器可以在握手完成后的任何时间通过发送CertificateRequest消息请求客户端身份验证。客户机必须使用适当的身份验证消息进行响应（参见第4.4节）。如果客户端选择进行身份验证，则必须发送证书、CertificateVerify、，
and Finished. If it declines, it MUST send a Certificate message containing no certificates followed by Finished. All of the client's messages for a given response MUST appear consecutively on the wire with no intervening messages of other types.
完成了。如果拒绝，它必须发送一条不包含证书的证书消息，后跟Finished。给定响应的所有客户端消息必须连续出现在线路上，没有其他类型的中间消息。
A client that receives a CertificateRequest message without having sent the "post_handshake_auth" extension MUST send an "unexpected_message" fatal alert.
如果客户端在未发送“post_handshake_auth”扩展名的情况下接收CertificateRequest消息，则必须发送“意外消息”致命警报。
Note: Because client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response. In addition, clients which receive multiple CertificateRequests in close succession MAY respond to them in a different order than they were received (the certificate_request_context value allows the server to disambiguate the responses).
注意：由于客户端身份验证可能涉及提示用户，因此服务器必须为一些延迟做好准备，包括在发送CertificateRequest和接收响应之间接收任意数量的其他消息。此外，连续接收多个CertificateRequests的客户端可能会以与接收到的顺序不同的顺序响应它们（certificate_request_上下文值允许服务器消除响应的歧义）。
The KeyUpdate handshake message is used to indicate that the sender is updating its sending cryptographic keys. This message can be sent by either peer after it has sent a Finished message. Implementations that receive a KeyUpdate message prior to receiving a Finished message MUST terminate the connection with an "unexpected_message" alert. After sending a KeyUpdate message, the sender SHALL send all its traffic using the next generation of keys, computed as described in Section 7.2. Upon receiving a KeyUpdate, the receiver MUST update its receiving keys.
KeyUpdate握手消息用于指示发送方正在更新其发送的加密密钥。此消息可以在发送完成的消息后由任一对等方发送。在接收完成消息之前接收KeyUpdate消息的实现必须使用“意外消息”警报终止连接。发送密钥更新消息后，发送方应使用第7.2节中所述计算的下一代密钥发送其所有通信量。接收到密钥更新后，接收器必须更新其接收密钥。
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
request_update: Indicates whether the recipient of the KeyUpdate should respond with its own KeyUpdate. If an implementation receives any other value, it MUST terminate the connection with an "illegal_parameter" alert.
request_update：指示KeyUpdate的收件人是否应使用其自己的KeyUpdate进行响应。如果实现收到任何其他值，它必须使用“非法_参数”警报终止连接。
If the request_update field is set to "update_requested", then the receiver MUST send a KeyUpdate of its own with request_update set to "update_not_requested" prior to sending its next Application Data record. This mechanism allows either side to force an update to the entire connection, but causes an implementation which receives
如果request_update字段设置为“update_requested”，则在发送下一个应用程序数据记录之前，接收方必须发送自己的密钥更新，request_update设置为“update_not_requested”。此机制允许任意一方强制更新整个连接，但会导致实现接收
multiple KeyUpdates while it is silent to respond with a single update. Note that implementations may receive an arbitrary number of messages between sending a KeyUpdate with request_update set to "update_requested" and receiving the peer's KeyUpdate, because those messages may already be in flight. However, because send and receive keys are derived from independent traffic secrets, retaining the receive traffic secret does not threaten the forward secrecy of data sent before the sender changed keys.
多个键更新，而它是无声的，以一个更新响应。注意，在发送request_update设置为“update_requested”的KeyUpdate和接收对等方的KeyUpdate之间，实现可能会接收任意数量的消息，因为这些消息可能已经在传输中。然而，由于发送和接收密钥来自独立的流量秘密，因此在发送方更改密钥之前，保留接收流量秘密不会威胁发送数据的前向保密性。
If implementations independently send their own KeyUpdates with request_update set to "update_requested" and they cross in flight, then each side will also send a response, with the result that each side increments by two generations.
如果实现独立地发送自己的密钥更新，并将request_update设置为“update_requested”，并且它们在飞行中交叉，那么每一方也将发送一个响应，结果是每一方增加两代。
Both sender and receiver MUST encrypt their KeyUpdate messages with the old keys. Additionally, both sides MUST enforce that a KeyUpdate with the old key is received before accepting any messages encrypted with the new key. Failure to do so may allow message truncation attacks.
发送方和接收方都必须使用旧密钥对其密钥更新消息进行加密。此外，双方必须强制在接受任何使用新密钥加密的消息之前，接收使用旧密钥的密钥更新。否则可能会导致消息截断攻击。
The TLS record protocol takes messages to be transmitted, fragments the data into manageable blocks, protects the records, and transmits the result. Received data is verified, decrypted, reassembled, and then delivered to higher-level clients.
TLS记录协议接收要传输的消息，将数据分割成可管理的块，保护记录，并传输结果。接收到的数据经过验证、解密、重新组装，然后发送到更高级别的客户端。
TLS records are typed, which allows multiple higher-level protocols to be multiplexed over the same record layer. This document specifies four content types: handshake, application_data, alert, and change_cipher_spec. The change_cipher_spec record is used only for compatibility purposes (see Appendix D.4).
TLS记录是类型化的，这允许在同一记录层上多路传输多个更高级别的协议。本文件规定了四种内容类型：握手、应用程序数据、警报和更改密码规范。更改密码规范记录仅用于兼容性目的（见附录D.4）。
An implementation may receive an unencrypted record of type change_cipher_spec consisting of the single byte value 0x01 at any time after the first ClientHello message has been sent or received and before the peer's Finished message has been received and MUST simply drop it without further processing. Note that this record may appear at a point at the handshake where the implementation is expecting protected records, and so it is necessary to detect this condition prior to attempting to deprotect the record. An implementation which receives any other change_cipher_spec value or which receives a protected change_cipher_spec record MUST abort the handshake with an "unexpected_message" alert. If an implementation detects a change_cipher_spec record received before the first ClientHello message or after the peer's Finished message, it MUST be treated as an unexpected record type (though stateless servers may not be able to distinguish these cases from allowed cases).
在发送或接收第一条ClientHello消息之后和接收对等方完成的消息之前的任何时间，实现可能会接收类型为change\u cipher\u spec的未加密记录，该记录由单字节值0x01组成，并且必须在不进行进一步处理的情况下删除该记录。请注意，此记录可能出现在握手时的某个点上，此时实现需要受保护的记录，因此有必要在尝试解除对记录的保护之前检测此情况。接收任何其他更改\u密码\u规范值或接收受保护更改\u密码\u规范记录的实现必须使用“意外消息”警报中止握手。如果实现检测到在第一条ClientHello消息之前或在对等方完成消息之后收到的change\u cipher\u spec记录，则必须将其视为意外的记录类型（尽管无状态服务器可能无法区分这些情况和允许的情况）。
Implementations MUST NOT send record types not defined in this document unless negotiated by some extension. If a TLS implementation receives an unexpected record type, it MUST terminate the connection with an "unexpected_message" alert. New record content type values are assigned by IANA in the TLS ContentType registry as described in Section 11.
除非通过某些扩展协商，否则实现不得发送本文档中未定义的记录类型。如果TLS实现接收到意外的记录类型，则必须使用“意外消息”警报终止连接。新的记录内容类型值由IANA在TLS ContentType注册表中分配，如第11节所述。
The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Message boundaries are handled differently depending on the underlying ContentType. Any future content types MUST specify appropriate rules. Note that these rules are stricter than what was enforced in TLS 1.2.
记录层将信息块分割成TLSPlaintext记录，其中包含2^14字节或更少的数据块。消息边界的处理方式因基础ContentType而异。任何未来的内容类型都必须指定适当的规则。请注意，这些规则比TLS 1.2中执行的规则更严格。
Handshake messages MAY be coalesced into a single TLSPlaintext record or fragmented across several records, provided that:
握手消息可以合并到单个TLSPlaintext记录中，也可以在多个记录中分段，前提是：
- Handshake messages MUST NOT be interleaved with other record types. That is, if a handshake message is split over two or more records, there MUST NOT be any other records between them.
- 握手消息不得与其他记录类型交错。也就是说，如果握手消息被拆分为两个或多个记录，则它们之间不得有任何其他记录。
- Handshake messages MUST NOT span key changes. Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert. Because the ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary.
- 握手消息不得跨越密钥更改。实现必须验证密钥更改之前的所有消息是否与记录边界对齐；如果没有，则必须使用“意外消息”警报终止连接。由于ClientHello、EndOfEarlyData、ServerHello、Finished和KeyUpdate消息可以在密钥更改之前立即发送，因此实现必须按照记录边界发送这些消息。
Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding.
实现不能发送握手类型的零长度片段，即使这些片段包含填充。
Alert messages (Section 6) MUST NOT be fragmented across records, and multiple alert messages MUST NOT be coalesced into a single TLSPlaintext record. In other words, a record with an Alert type MUST contain exactly one message.
警报消息（第6节）不得跨记录分段，且多条警报消息不得合并到单个TLSPlaintext记录中。换句话说，具有警报类型的记录必须仅包含一条消息。
Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record.
应用程序数据消息包含对TLS不透明的数据。应用程序数据消息始终受到保护。可以发送应用程序数据的零长度片段，因为它们可能用作流量分析对策。应用程序数据片段可以跨多个记录拆分，也可以合并为单个记录。
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
(255)
} ContentType;
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
(255)
} ContentType;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
type: The higher-level protocol used to process the enclosed fragment.
类型：用于处理封闭片段的高级协议。
legacy_record_version: MUST be set to 0x0303 for all records generated by a TLS 1.3 implementation other than an initial ClientHello (i.e., one not generated after a HelloRetryRequest), where it MAY also be 0x0301 for compatibility purposes. This field is deprecated and MUST be ignored for all purposes. Previous versions of TLS would use other values in this field under some circumstances.
遗留_记录_版本：对于由TLS 1.3实现生成的所有记录，必须将其设置为0x0303，而不是初始ClientHello（即，在HelloRetryRequest之后未生成的记录），出于兼容性目的，该版本也可能为0x0301。此字段已弃用，因此必须忽略。以前版本的TLS在某些情况下会使用此字段中的其他值。
length: The length (in bytes) of the following TLSPlaintext.fragment. The length MUST NOT exceed 2^14 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert.
长度：以下TLSPlaintext.fragment的长度（以字节为单位）。长度不得超过2^14字节。接收超过此长度的记录的端点必须使用“记录溢出”警报终止连接。
fragment: The data being transmitted. This value is transparent and is treated as an independent block to be dealt with by the higher-level protocol specified by the type field.
片段：正在传输的数据。此值是透明的，并被视为独立块，由类型字段指定的更高级别协议处理。
This document describes TLS 1.3, which uses the version 0x0304. This version value is historical, deriving from the use of 0x0301 for TLS 1.0 and 0x0300 for SSL 3.0. In order to maximize backward compatibility, a record containing an initial ClientHello SHOULD have version 0x0301 (reflecting TLS 1.0) and a record containing a second ClientHello or a ServerHello MUST have version 0x0303 (reflecting TLS 1.2). When negotiating prior versions of TLS, endpoints follow the procedure and requirements provided in Appendix D.
本文档描述了TLS 1.3，它使用的是版本0x0304。此版本值是历史值，源于对TLS 1.0使用0x0301和对SSL 3.0使用0x0300。为了最大化向后兼容性，包含初始ClientHello的记录应具有版本0x0301（反映TLS 1.0），包含第二个ClientHello或ServerHello的记录必须具有版本0x0303（反映TLS 1.2）。在协商之前版本的TLS时，端点遵循附录D中提供的程序和要求。
When record protection has not yet been engaged, TLSPlaintext structures are written directly onto the wire. Once record protection has started, TLSPlaintext records are protected and sent as described in the following section. Note that Application Data records MUST NOT be written to the wire unprotected (see Section 2 for details).
当尚未启用记录保护时，TLSPlaintext结构将直接写入到导线上。一旦开始记录保护，TLSPlaintext记录将按照下一节所述进行保护和发送。请注意，应用程序数据记录不得写入未受保护的导线（有关详细信息，请参阅第2节）。
The record protection functions translate a TLSPlaintext structure into a TLSCiphertext structure. The deprotection functions reverse the process. In TLS 1.3, as opposed to previous versions of TLS, all ciphers are modeled as "Authenticated Encryption with Associated Data" (AEAD) [RFC5116]. AEAD functions provide a unified encryption and authentication operation which turns plaintext into authenticated ciphertext and back again. Each encrypted record consists of a plaintext header followed by an encrypted body, which itself contains a type and optional padding.
记录保护功能将TLSPlaintText结构转换为TLSCiphertext结构。脱保护功能可逆转该过程。在TLS 1.3中，与以前版本的TLS不同，所有密码都建模为“关联数据的认证加密”（AEAD）[RFC5116]。AEAD函数提供统一的加密和身份验证操作，将明文转换为经过身份验证的密文，然后再转换回来。每个加密记录都由一个明文头和一个加密体组成，加密体本身包含一个类型和可选的填充。
struct {
opaque content[TLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} TLSInnerPlaintext;
struct {
opaque content[TLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} TLSInnerPlaintext;
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
content: The TLSPlaintext.fragment value, containing the byte encoding of a handshake or an alert message, or the raw bytes of the application's data to send.
内容：TLSPlaintext.fragment值，包含握手或警报消息的字节编码，或要发送的应用程序数据的原始字节。
type: The TLSPlaintext.type value containing the content type of the record.
类型：包含记录内容类型的TLSPlaintext.type值。
zeros: An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field. This provides an opportunity for senders to pad any TLS record by a chosen amount as long as the total stays within record size limits. See Section 5.4 for more details.
零：类型字段后的明文中可能出现任意长度的零值字节。这为发送方提供了一个机会，只要总数保持在记录大小限制内，发送方就可以按选定的数量填充任何TLS记录。详见第5.4节。
opaque_type: The outer opaque_type field of a TLSCiphertext record is always set to the value 23 (application_data) for outward compatibility with middleboxes accustomed to parsing previous versions of TLS. The actual content type of the record is found in TLSInnerPlaintext.type after decryption.
不透明_类型：TLSCiphertext记录的外部不透明_类型字段始终设置为值23（应用程序_数据），以便与习惯于解析TLS早期版本的中间盒向外兼容。解密后，记录的实际内容类型在TLSInnerPlaintext.type中找到。
legacy_record_version: The legacy_record_version field is always 0x0303. TLS 1.3 TLSCiphertexts are not generated until after TLS 1.3 has been negotiated, so there are no historical compatibility concerns where other values might be received. Note that the handshake protocol, including the ClientHello and ServerHello messages, authenticates the protocol version, so this value is redundant.
遗留_记录_版本：遗留_记录_版本字段始终为0x0303。TLS 1.3 TLSCipherText在TLS 1.3协商后才会生成，因此在可能收到其他值的情况下，不存在历史兼容性问题。请注意，握手协议（包括ClientHello和ServerHello消息）验证协议版本，因此该值是冗余的。
length: The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. The length MUST NOT exceed 2^14 + 256 bytes. An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert.
长度：以下TLSCiphertext.encrypted_记录的长度（以字节为单位），它是内容和填充的长度之和，加上内部内容类型的长度，再加上AEAD算法添加的任何扩展。长度不得超过2^14+256字节。接收超过此长度的记录的端点必须使用“记录溢出”警报终止连接。
encrypted_record: The AEAD-encrypted form of the serialized TLSInnerPlaintext structure.
encrypted_record：序列化TLSInnerPlaintext结构的AEAD加密形式。
AEAD algorithms take as input a single key, a nonce, a plaintext, and "additional data" to be included in the authentication check, as described in Section 2.1 of [RFC5116]. The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number and the client_write_iv or server_write_iv (see Section 5.3), and the additional data input is the record header.
AEAD算法将单个密钥、nonce、明文和“附加数据”作为输入，以包括在认证检查中，如[RFC5116]第2.1节所述。密钥为客户机写入密钥或服务器写入密钥，nonce来自序列号和客户机写入iv或服务器写入iv（参见第5.3节），额外的数据输入为记录头。
I.e.,
即。，
additional_data = TLSCiphertext.opaque_type || TLSCiphertext.legacy_record_version || TLSCiphertext.length
附加_数据=TLSCiphertext.opaque_类型| | TLSCiphertext.legacy_记录|版本| | TLSCiphertext.length
The plaintext input to the AEAD algorithm is the encoded TLSInnerPlaintext structure. Derivation of traffic keys is defined in Section 7.3.
AEAD算法的明文输入是编码的TLR文本结构。第7.3节定义了交通钥匙的推导。
The AEAD output consists of the ciphertext output from the AEAD encryption operation. The length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. The length of the AEAD output will generally be larger than the plaintext, but by an amount that varies with the AEAD algorithm.
AEAD输出由AEAD加密操作的密文输出组成。由于包含TLSINERPLAINTEXT.type和发送方提供的任何填充，纯文本的长度大于相应的TLSPlaintext.length。AEAD输出的长度通常会大于纯文本，但会随AEAD算法的不同而变化。
Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext. Symbolically,
由于密码可能包含填充，因此开销量可能随明文长度的不同而变化。象征性地
AEADEncrypted = AEAD-Encrypt(write_key, nonce, additional_data, plaintext)
AEADEncrypted=AEAD加密（写入密钥、nonce、附加数据、明文）
The encrypted_record field of TLSCiphertext is set to AEADEncrypted.
TLSCiphertext的加密记录字段设置为AEADEncrypted。
In order to decrypt and verify, the cipher takes as input the key, nonce, additional data, and the AEADEncrypted value. The output is either the plaintext or an error indicating that the decryption failed. There is no separate integrity check. Symbolically,
为了解密和验证，密码将密钥、nonce、附加数据和AEADEncrypted值作为输入。输出为纯文本或指示解密失败的错误。没有单独的完整性检查。象征性地
plaintext of encrypted_record = AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)
加密记录的明文=AEAD解密（对等写入密钥、nonce、附加数据、AEAD加密）
If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.
如果解密失败，接收器必须通过“bad_record_mac”警报终止连接。
An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion greater than 255 octets. An endpoint that receives a record from its peer with TLSCiphertext.length larger than 2^14 + 256 octets MUST terminate the connection with a "record_overflow" alert. This limit is derived from the maximum TLSInnerPlaintext length of 2^14 octets + 1 octet for ContentType + the maximum AEAD expansion of 255 octets.
TLS 1.3中使用的AEAD算法不得产生大于255个八位字节的扩展。从其对等方接收TLSCiphertext.length大于2^14+256个八位字节的记录的终结点必须使用“记录溢出”警报终止连接。此限制源自最大TLR文本长度2^14个八位字节+ContentType的1个八位字节+最大AEAD扩展255个八位字节。
A 64-bit sequence number is maintained separately for reading and writing records. The appropriate sequence number is incremented by one after reading or writing each record. Each sequence number is set to zero at the beginning of a connection and whenever the key is changed; the first record transmitted under a particular traffic key MUST use sequence number 0.
64位序列号分别用于读取和写入记录。读取或写入每条记录后，相应的序列号将递增1。每个序列号在连接开始时和钥匙更改时设置为零；在特定通信密钥下传输的第一条记录必须使用序号0。
Because the size of sequence numbers is 64-bit, they should not wrap. If a TLS implementation would need to wrap a sequence number, it MUST either rekey (Section 4.6.3) or terminate the connection.
因为序列号的大小是64位的，所以它们不应该换行。如果TLS实现需要包装一个序列号，则必须重新输入（第4.6.3节）或终止连接。
Each AEAD algorithm will specify a range of possible lengths for the per-record nonce, from N_MIN bytes to N_MAX bytes of input [RFC5116]. The length of the TLS per-record nonce (iv_length) is set to the larger of 8 bytes and N_MIN for the AEAD algorithm (see [RFC5116], Section 4). An AEAD algorithm where N_MAX is less than 8 bytes MUST NOT be used with TLS. The per-record nonce for the AEAD construction is formed as follows:
每个AEAD算法将为每个记录指定一个可能的长度范围，从输入的N_最小字节到N_最大字节[RFC5116]。对于AEAD算法，每个记录nonce的TLS长度（iv_长度）设置为8字节和N_MIN中的较大值（参见[RFC5116]，第4节）。N_MAX小于8字节的AEAD算法不得与TLS一起使用。AEAD构造的每记录临时值的格式如下：
1. The 64-bit record sequence number is encoded in network byte order and padded to the left with zeros to iv_length.
1. 64位记录序列号按网络字节顺序编码，并用0填充到iv_长度。
2. The padded sequence number is XORed with either the static client_write_iv or server_write_iv (depending on the role).
2. 填充序列号与静态客户端\写入\ iv或服务器\写入\ iv（取决于角色）异或。
The resulting quantity (of length iv_length) is used as the per-record nonce.
生成的数量（长度为iv_长度）用作每个记录的当前值。
Note: This is a different construction from that in TLS 1.2, which specified a partially explicit nonce.
注：这与TLS 1.2中的构造不同，TLS 1.2中规定了部分显式nonce。
All encrypted TLS records can be padded to inflate the size of the TLSCiphertext. This allows the sender to hide the size of the traffic from an observer.
可以填充所有加密的TLS记录以增大TLS文本的大小。这允许发送方对观察者隐藏通信量的大小。
When generating a TLSCiphertext record, implementations MAY choose to pad. An unpadded record is just a record with a padding length of zero. Padding is a string of zero-valued bytes appended to the ContentType field before encryption. Implementations MUST set the padding octets to all zeros before encrypting.
生成TLSCiphertext记录时，实现可以选择填充。未添加的记录只是填充长度为零的记录。填充是加密前附加到ContentType字段的零值字节字符串。在加密之前，实现必须将填充八位字节设置为全零。
Application Data records may contain a zero-length TLSInnerPlaintext.content if the sender desires. This permits generation of plausibly sized cover traffic in contexts where the presence or absence of activity may be sensitive. Implementations MUST NOT send Handshake and Alert records that have a zero-length TLSInnerPlaintext.content; if such a message is received, the receiving implementation MUST terminate the connection with an "unexpected_message" alert.
如果发送方愿意，应用程序数据记录可能包含长度为零的TLSInnerPlaintext.content。这允许在活动的存在或不存在可能是敏感的情况下生成合理大小的覆盖流量。实现不得发送长度为零的握手和警报记录TLSInnerPlaintext.content；如果收到此类消息，则接收实现必须使用“意外消息”警报终止连接。
The padding sent is automatically verified by the record protection mechanism; upon successful decryption of a TLSCiphertext.encrypted_record, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero octet. This non-zero octet is the content type of the message. This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types. The design also enforces all-zero padding octets, which allows for quick detection of padding errors.
发送的填充由记录保护机制自动验证；成功解密TLSCiphertext.encrypted_记录后，接收实现会从头到尾扫描字段，直到找到非零八位字节。此非零八位字节是消息的内容类型。之所以选择此填充方案，是因为它允许按任意大小（从零到TLS记录大小限制）填充任何加密的TLS记录，而无需引入新的内容类型。该设计还强制执行所有零填充八位字节，这允许快速检测填充错误。
Implementations MUST limit their scanning to the cleartext returned from the AEAD decryption. If a receiving implementation does not find a non-zero octet in the cleartext, it MUST terminate the connection with an "unexpected_message" alert.
实现必须将扫描限制为AEAD解密返回的明文。如果接收实现未在明文中找到非零八位字节，则必须使用“意外消息”警报终止连接。
The presence of padding does not change the overall record size limitations: the full encoded TLSInnerPlaintext MUST NOT exceed 2^14 + 1 octets. If the maximum fragment length is reduced -- as, for example, by the record_size_limit extension from [RFC8449] -- then the reduced limit applies to the full plaintext, including the content type and padding.
填充的存在不会改变总体记录大小限制：完整编码的TLR文本不得超过2^14+1个八位字节。如果最大片段长度减少了（例如，通过[RFC8449]的记录大小限制扩展），则减少的限制将应用于全文，包括内容类型和填充。
Selecting a padding policy that suggests when and how much to pad is a complex topic and is beyond the scope of this specification. If the application-layer protocol on top of TLS has its own padding, it may be preferable to pad Application Data TLS records within the application layer. Padding for encrypted Handshake or Alert records must still be handled at the TLS layer, though. Later documents may define padding selection algorithms or define a padding policy request mechanism through TLS extensions or some other means.
选择建议何时填充以及填充多少的填充策略是一个复杂的主题，超出了本规范的范围。如果TLS上的应用层协议有自己的填充，则最好在应用层内填充应用数据TLS记录。不过，加密握手或警报记录的填充仍必须在TLS层处理。稍后的文档可能会定义填充选择算法，或者通过TLS扩展或其他方式定义填充策略请求机制。
There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys. [AEAD-LIMITS] provides an analysis of these limits under the assumption that the underlying primitive (AES or ChaCha20) has no weaknesses. Implementations SHOULD do a key update as described in Section 4.6.3 prior to reaching these limits.
在给定的密钥集下，可以安全加密的明文数量有密码限制。[AEAD-LIMITS]在假设基础原语（AES或ChaCha20）没有弱点的情况下，对这些限制进行分析。在达到这些限制之前，实施应按照第4.6.3节所述进行密钥更新。
For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of approximately 2^-57 for Authenticated Encryption (AE) security. For ChaCha20/Poly1305, the record sequence number would wrap before the safety limit is reached.
对于AES-GCM，在给定连接上最多可以加密2^-24.5条完整大小的记录（约2400万条），同时为认证加密（AE）安全性保留约2^-57的安全裕度。对于ChaCha20/Poly1305，记录序列号将在达到安全限值之前包装。
TLS provides an Alert content type to indicate closure information and errors. Like other messages, alert messages are encrypted as specified by the current connection state.
TLS提供警报内容类型以指示关闭信息和错误。与其他消息一样，警报消息按照当前连接状态的指定进行加密。
Alert messages convey a description of the alert and a legacy field that conveyed the severity level of the message in previous versions of TLS. Alerts are divided into two classes: closure alerts and error alerts. In TLS 1.3, the severity is implicit in the type of alert being sent, and the "level" field can safely be ignored. The "close_notify" alert is used to indicate orderly closure of one direction of the connection. Upon receiving such an alert, the TLS implementation SHOULD indicate end-of-data to the application.
警报消息传达警报的说明，以及传达早期版本TLS中消息严重性级别的传统字段。警报分为两类：关闭警报和错误警报。在TLS 1.3中，严重性隐含在发送的警报类型中，“级别”字段可以安全地忽略。“close_notify”（关闭通知）警报用于指示连接的一个方向有序关闭。收到此类警报后，TLS实现应向应用程序指示数据结束。
Error alerts indicate abortive closure of the connection (see Section 6.2). Upon receiving an error alert, the TLS implementation SHOULD indicate an error to the application and MUST NOT allow any further data to be sent or received on the connection. Servers and clients MUST forget the secret values and keys established in failed connections, with the exception of the PSKs associated with session tickets, which SHOULD be discarded if possible.
错误警报表示连接已中止关闭（请参阅第6.2节）。收到错误警报后，TLS实现应向应用程序指示错误，并且不得允许在连接上发送或接收任何进一步的数据。服务器和客户端必须忘记在失败的连接中建立的秘密值和密钥，与会话票证关联的PSK除外，如果可能的话，应将其丢弃。
All the alerts listed in Section 6.2 MUST be sent with AlertLevel=fatal and MUST be treated as error alerts when received regardless of the AlertLevel in the message. Unknown Alert types MUST be treated as error alerts.
第6.2节中列出的所有警报必须使用AlertLevel=fatal发送，并且无论消息中的警报级别如何，在收到时都必须视为错误警报。未知警报类型必须视为错误警报。
Note: TLS defines two generic alerts (see Section 6) to use upon failure to parse a message. Peers which receive a message which cannot be parsed according to the syntax (e.g., have a length extending beyond the message boundary or contain an out-of-range length) MUST terminate the connection with a "decode_error" alert. Peers which receive a message which is syntactically correct but semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) MUST terminate the connection with an "illegal_parameter" alert.
注：TLS定义了两个通用警报（见第6节），用于在解析消息失败时使用。接收到无法根据语法解析的消息（例如，长度超出消息边界或包含超出范围的长度）的对等方必须使用“解码错误”警报终止连接。接收到语法正确但语义无效的消息（例如，p-1的DHE共享或无效枚举）的对等方必须使用“非法_参数”警报终止连接。
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
record_overflow(22),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
missing_extension(109),
unsupported_extension(110),
unrecognized_name(112),
bad_certificate_status_response(113),
unknown_psk_identity(115),
certificate_required(116),
no_application_protocol(120),
(255)
} AlertDescription;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
record_overflow(22),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
missing_extension(109),
unsupported_extension(110),
unrecognized_name(112),
bad_certificate_status_response(113),
unknown_psk_identity(115),
certificate_required(116),
no_application_protocol(120),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack.
客户端和服务器必须共享连接即将结束的知识，以避免截断攻击。
close_notify: This alert notifies the recipient that the sender will not send any more messages on this connection. Any data received after a closure alert has been received MUST be ignored.
close_notify：此警报通知收件人发件人将不再在此连接上发送任何邮件。必须忽略在收到关闭警报后收到的任何数据。
user_canceled: This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure. If a user cancels an operation after the handshake is complete, just closing the connection by sending a "close_notify" is more appropriate. This alert SHOULD be followed by a "close_notify". This alert generally has AlertLevel=warning.
user_Cancelled：此警报通知收件人发件人因与协议故障无关的原因取消握手。如果用户在握手完成后取消操作，则只需发送“close_notify”来关闭连接就更合适了。此警报后应显示“关闭通知”。此警报通常具有AlertLevel=警告。
Either party MAY initiate a close of its write side of the connection by sending a "close_notify" alert. Any data received after a closure alert has been received MUST be ignored. If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received.
任何一方都可以通过发送“close_notify”警报来关闭其连接的写入端。必须忽略在收到关闭警报后收到的任何数据。如果在“关闭通知”之前接收到传输级关闭，则接收器无法知道已发送的所有数据均已接收。
Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert. This does not have any effect on its read side of the connection. Note that this is a change from versions of TLS prior to TLS 1.3 in which implementations were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own. That previous requirement could cause truncation in the read side. Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation.
各方必须在关闭其连接的写入端之前发送“close_notify”警报，除非它已经发送了一些错误警报。这对连接的读取端没有任何影响。请注意，这与TLS 1.3之前的TLS版本有所不同，在TLS 1.3版本中，要求实现通过放弃挂起的写入并立即发送自己的“关闭通知”警报来对“关闭通知”作出反应。前面的要求可能会导致读取端的截断。在关闭连接的读取端之前，双方无需等待收到“close_notify”警报，尽管这样做会引入截断的可能性。
If the application protocol using TLS provides that any data may be carried over the underlying transport after the TLS connection is closed, the TLS implementation MUST receive a "close_notify" alert before indicating end-of-data to the application layer. No part of this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when connections are opened or closed.
如果使用TLS的应用程序协议规定，在TLS连接关闭后，任何数据都可能通过底层传输传输，则TLS实现必须在向应用程序层指示数据结束之前收到“close_notify”警报。本标准的任何部分都不应规定TLS使用概要文件管理其数据传输的方式，包括连接打开或关闭时的方式。
Note: It is assumed that closing the write side of a connection reliably delivers pending data before destroying the transport.
注意：假定在销毁传输之前，关闭连接的写端可以可靠地传递挂起的数据。
Error handling in TLS is very simple. When an error is detected, the detecting party sends a message to its peer. Upon transmission or receipt of a fatal alert message, both parties MUST immediately close the connection.
TLS中的错误处理非常简单。当检测到错误时，检测方向其对等方发送消息。在传输或接收到致命警报消息后，双方必须立即关闭连接。
Whenever an implementation encounters a fatal error condition, it SHOULD send an appropriate fatal alert and MUST close the connection without sending or receiving any additional data. In the rest of this specification, when the phrases "terminate the connection" and "abort the handshake" are used without a specific alert it means that the implementation SHOULD send the alert indicated by the descriptions below. The phrases "terminate the connection with an X alert" and "abort the handshake with an X alert" mean that the implementation MUST send alert X if it sends any alert. All alerts defined below in this section, as well as all unknown alerts, are universally considered fatal as of TLS 1.3 (see Section 6). The implementation SHOULD provide a way to facilitate logging the sending and receiving of alerts.
每当实现遇到致命错误时，它都应该发送相应的致命警报，并且必须在不发送或接收任何其他数据的情况下关闭连接。在本规范的其余部分中，当使用短语“终止连接”和“中止握手”时，没有特定的警报，这意味着实现应发送以下描述所示的警报。短语“使用X警报终止连接”和“使用X警报中止握手”意味着，如果实现发送任何警报，它必须发送警报X。从TLS 1.3开始，本节中定义的所有警报以及所有未知警报都被普遍认为是致命的（见第6节）。该实现应提供一种方便记录警报发送和接收的方法。
The following error alerts are defined:
定义了以下错误警报：
unexpected_message: An inappropriate message (e.g., the wrong handshake message, premature Application Data, etc.) was received. This alert should never be observed in communication between proper implementations.
意外的_消息：收到不适当的消息（例如，错误的握手消息、过早的应用程序数据等）。在正确实现之间的通信中，不应出现此警报。
bad_record_mac: This alert is returned if a record is received which cannot be deprotected. Because AEAD algorithms combine decryption and verification, and also to avoid side-channel attacks, this alert is used for all deprotection failures. This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network.
bad_record_mac：如果收到无法解除保护的记录，将返回此警报。由于AEAD算法结合了解密和验证，并避免了侧通道攻击，因此此警报用于所有解除保护失败。除非消息在网络中被破坏，否则在正确实现之间的通信中不应出现此警报。
record_overflow: A TLSCiphertext record was received that had a length more than 2^14 + 256 bytes, or a record decrypted to a TLSPlaintext record with more than 2^14 bytes (or some other negotiated limit). This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network.
记录溢出：接收到长度超过2^14+256字节的TLSCiphertext记录，或解密为长度超过2^14字节（或其他协商限制）的TLSPlaintext记录。除非消息在网络中被破坏，否则在正确实现之间的通信中不应出现此警报。
handshake_failure: Receipt of a "handshake_failure" alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available.
握手失败：收到“握手失败”警报消息表明，在提供可用选项的情况下，发送方无法协商一组可接受的安全参数。
bad_certificate: A certificate was corrupt, contained signatures that did not verify correctly, etc.
坏证书：证书已损坏，包含未正确验证的签名等。
unsupported_certificate: A certificate was of an unsupported type.
不支持的\u证书：证书的类型不受支持。
certificate_revoked: A certificate was revoked by its signer.
证书被吊销：证书已被其签名者吊销。
certificate_expired: A certificate has expired or is not currently valid.
证书\u过期：证书已过期或当前无效。
certificate_unknown: Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable.
证书\u未知：处理证书时出现其他一些（未指定）问题，使其无法接受。
illegal_parameter: A field in the handshake was incorrect or inconsistent with other fields. This alert is used for errors which conform to the formal protocol syntax but are otherwise incorrect.
非法参数：握手中的字段不正确或与其他字段不一致。此警报用于符合正式协议语法但在其他方面不正确的错误。
unknown_ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known trust anchor.
未知\u ca:收到了有效的证书链或部分链，但证书未被接受，因为找不到ca证书或无法与已知信任锚点匹配。
access_denied: A valid certificate or PSK was received, but when access control was applied, the sender decided not to proceed with negotiation.
拒绝访问：收到有效的证书或PSK，但当应用访问控制时，发件人决定不继续协商。
decode_error: A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This alert is used for errors where the message does not conform to the formal protocol syntax. This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network.
解码_错误：无法解码消息，因为某些字段超出指定范围或消息长度不正确。此警报用于消息不符合正式协议语法的错误。除非消息在网络中被破坏，否则在正确实现之间的通信中不应出现此警报。
decrypt_error: A handshake (not record layer) cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message or a PSK binder.
解密_错误：握手（非记录层）加密操作失败，包括无法正确验证签名或验证完成的消息或PSK绑定。
protocol_version: The protocol version the peer has attempted to negotiate is recognized but not supported (see Appendix D).
协议版本：对等方试图协商的协议版本已被识别，但不受支持（见附录D）。
insufficient_security: Returned instead of "handshake_failure" when a negotiation has failed specifically because the server requires parameters more secure than those supported by the client.
安全性不足：当协商失败时，返回而不是“握手失败”，特别是因为服务器需要比客户端支持的参数更安全的参数。
internal_error: An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible to continue.
内部错误：与对等方或协议正确性无关的内部错误（如内存分配失败）导致无法继续。
inappropriate_fallback: Sent by a server in response to an invalid connection retry attempt from a client (see [RFC7507]).
不适当的_回退：由服务器发送，以响应来自客户端的无效连接重试尝试（请参阅[RFC7507]）。
missing_extension: Sent by endpoints that receive a handshake message not containing an extension that is mandatory to send for the offered TLS version or other negotiated parameters.
缺少扩展名：由接收握手消息的端点发送，该消息不包含针对提供的TLS版本或其他协商参数必须发送的扩展名。
unsupported_extension: Sent by endpoints receiving any handshake message containing an extension known to be prohibited for inclusion in the given handshake message, or including any extensions in a ServerHello or Certificate not first offered in the corresponding ClientHello or CertificateRequest.
不受支持的扩展名：由接收任何握手消息的端点发送，该消息包含已知禁止包含在给定握手消息中的扩展名，或包含ServerHello或证书中的任何扩展名，而不是首先在相应的ClientHello或CertificateRequest中提供。
unrecognized_name: Sent by servers when no server exists identified by the name provided by the client via the "server_name" extension (see [RFC6066]).
无法识别的_名称：当不存在由客户端通过“服务器_名称”扩展提供的名称标识的服务器时，服务器发送（请参阅[RFC6066]）。
bad_certificate_status_response: Sent by clients when an invalid or unacceptable OCSP response is provided by the server via the "status_request" extension (see [RFC6066]).
错误的\u证书\u状态\u响应：当服务器通过“状态请求”扩展提供无效或不可接受的OCSP响应时，由客户端发送（请参阅[RFC6066]）。
unknown_psk_identity: Sent by servers when PSK key establishment is desired but no acceptable PSK identity is provided by the client. Sending this alert is OPTIONAL; servers MAY instead choose to send a "decrypt_error" alert to merely indicate an invalid PSK identity.
未知psk_标识：当需要建立psk密钥，但客户端未提供可接受的psk标识时，由服务器发送。发送此警报是可选的；服务器可能会选择发送“decrypt_error”（解密错误）警报，以仅指示无效的PSK标识。
certificate_required: Sent by servers when a client certificate is desired but none was provided by the client.
需要证书：当需要客户端证书但客户端未提供证书时，由服务器发送。
no_application_protocol: Sent by servers when a client "application_layer_protocol_negotiation" extension advertises only protocols that the server does not support (see [RFC7301]).
无应用程序协议：当客户端“应用程序层协议协商”扩展仅播发服务器不支持的协议时，服务器发送（请参阅[RFC7301]）。
New Alert values are assigned by IANA as described in Section 11.
新警报值由IANA分配，如第11节所述。
The TLS handshake establishes one or more input secrets which are combined to create the actual working keying material, as detailed below. The key derivation process incorporates both the input secrets and the handshake transcript. Note that because the handshake transcript includes the random values from the Hello messages, any given handshake will have different traffic secrets, even if the same input secrets are used, as is the case when the same PSK is used for multiple connections.
TLS握手建立了一个或多个输入机密，这些机密被组合起来以创建实际的工作键控材料，如下所述。密钥派生过程包含输入秘密和握手记录。请注意，因为握手记录包括来自Hello消息的随机值，所以任何给定的握手都将具有不同的流量机密，即使使用相同的输入机密，就像在多个连接中使用相同的PSK一样。
The key derivation process makes use of the HKDF-Extract and HKDF-Expand functions as defined for HKDF [RFC5869], as well as the functions defined below:
密钥派生过程使用为HKDF[RFC5869]定义的HKDF提取和HKDF扩展函数，以及以下定义的函数：
HKDF-Expand-Label(Secret, Label, Context, Length) = HKDF-Expand(Secret, HkdfLabel, Length)
HKDF扩展标签（机密、标签、上下文、长度）=HKDF扩展（机密、HkdfLabel、长度）
Where HkdfLabel is specified as:
其中HkdfLabel指定为：
struct {
uint16 length = Length;
opaque label<7..255> = "tls13 " + Label;
opaque context<0..255> = Context;
} HkdfLabel;
struct {
uint16 length = Length;
opaque label<7..255> = "tls13 " + Label;
opaque context<0..255> = Context;
} HkdfLabel;
Derive-Secret(Secret, Label, Messages) = HKDF-Expand-Label(Secret, Label, Transcript-Hash(Messages), Hash.length)
派生机密（机密、标签、消息）=HKDF扩展标签（机密、标签、转录本哈希（消息）、哈希.长度）
The Hash function used by Transcript-Hash and HKDF is the cipher suite hash algorithm. Hash.length is its output length in bytes. Messages is the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers. Note that in some cases a zero-length Context (indicated by "") is passed to HKDF-Expand-Label. The labels specified in this document are all ASCII strings and do not include a trailing NUL byte.
转录哈希和HKDF使用的哈希函数是密码套件哈希算法。Hash.length是其输出长度（以字节为单位）。消息是所指示的握手消息的串联，包括握手消息类型和长度字段，但不包括记录层头。请注意，在某些情况下，将零长度上下文（由“”表示）传递给HKDF Expand Label。本文档中指定的标签均为ASCII字符串，不包含尾随NUL字节。
Note: With common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute. The labels in this specification have all been chosen to fit within this limit.
注意：对于常见的哈希函数，任何长度超过12个字符的标签都需要额外的哈希函数迭代来计算。本规范中的标签均已选定，以符合此限制。
Keys are derived from two input secrets using the HKDF-Extract and Derive-Secret functions. The general pattern for adding a new secret is to use HKDF-Extract with the Salt being the current secret state and the Input Keying Material (IKM) being the new secret to be added. In this version of TLS 1.3, the two input secrets are:
使用HKDF Extract和Derive Secret函数从两个输入机密中派生密钥。添加新秘密的一般模式是使用HKDF Extract，其中Salt是当前秘密状态，输入键控材料（IKM）是要添加的新秘密。在TLS 1.3的这个版本中，两个输入秘密是：
- PSK (a pre-shared key established externally or derived from the resumption_master_secret value from a previous connection)
- PSK（从外部建立或从先前连接的恢复\u主\u秘密值派生的预共享密钥）
- (EC)DHE shared secret (Section 7.4)
- （EC）DHE共享机密（第7.4节）
This produces a full key derivation schedule shown in the diagram below. In this diagram, the following formatting conventions apply:
这将生成一个完整的密钥派生计划，如下图所示。在此图中，以下格式约定适用：
- HKDF-Extract is drawn as taking the Salt argument from the top and the IKM argument from the left, with its output to the bottom and the name of the output on the right.
- HKDF Extract绘制为从顶部获取Salt参数，从左侧获取IKM参数，其输出位于底部，输出名称位于右侧。
- Derive-Secret's Secret argument is indicated by the incoming arrow. For instance, the Early Secret is the Secret for generating the client_early_traffic_secret.
- 派生机密的机密参数由传入的箭头指示。例如，Early Secret是用于生成客户端\u Early\u流量\u Secret的密钥。
- "0" indicates a string of Hash.length bytes set to zero.
- “0”表示设置为零的Hash.length字节字符串。
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(., "ext binder" | "res binder", "")
| = binder_key
|
+-----> Derive-Secret(., "c e traffic", ClientHello)
| = client_early_traffic_secret
|
+-----> Derive-Secret(., "e exp master", ClientHello)
| = early_exporter_master_secret
v
Derive-Secret(., "derived", "")
|
v
(EC)DHE -> HKDF-Extract = Handshake Secret
|
+-----> Derive-Secret(., "c hs traffic",
| ClientHello...ServerHello)
| = client_handshake_traffic_secret
|
+-----> Derive-Secret(., "s hs traffic",
| ClientHello...ServerHello)
| = server_handshake_traffic_secret
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(., "c ap traffic",
| ClientHello...server Finished)
| = client_application_traffic_secret_0
|
+-----> Derive-Secret(., "s ap traffic",
| ClientHello...server Finished)
| = server_application_traffic_secret_0
|
+-----> Derive-Secret(., "exp master",
| ClientHello...server Finished)
| = exporter_master_secret
|
+-----> Derive-Secret(., "res master",
ClientHello...client Finished)
= resumption_master_secret
0
|
v
PSK -> HKDF-Extract = Early Secret
|
+-----> Derive-Secret(., "ext binder" | "res binder", "")
| = binder_key
|
+-----> Derive-Secret(., "c e traffic", ClientHello)
| = client_early_traffic_secret
|
+-----> Derive-Secret(., "e exp master", ClientHello)
| = early_exporter_master_secret
v
Derive-Secret(., "derived", "")
|
v
(EC)DHE -> HKDF-Extract = Handshake Secret
|
+-----> Derive-Secret(., "c hs traffic",
| ClientHello...ServerHello)
| = client_handshake_traffic_secret
|
+-----> Derive-Secret(., "s hs traffic",
| ClientHello...ServerHello)
| = server_handshake_traffic_secret
v
Derive-Secret(., "derived", "")
|
v
0 -> HKDF-Extract = Master Secret
|
+-----> Derive-Secret(., "c ap traffic",
| ClientHello...server Finished)
| = client_application_traffic_secret_0
|
+-----> Derive-Secret(., "s ap traffic",
| ClientHello...server Finished)
| = server_application_traffic_secret_0
|
+-----> Derive-Secret(., "exp master",
| ClientHello...server Finished)
| = exporter_master_secret
|
+-----> Derive-Secret(., "res master",
ClientHello...client Finished)
= resumption_master_secret
The general pattern here is that the secrets shown down the left side of the diagram are just raw entropy without context, whereas the secrets down the right side include Handshake Context and therefore can be used to derive working keys without additional context. Note that the different calls to Derive-Secret may take different Messages arguments, even with the same secret. In a 0-RTT exchange, Derive-Secret is called with four distinct transcripts; in a 1-RTT-only exchange, it is called with three distinct transcripts.
这里的一般模式是，图左侧下方显示的秘密只是没有上下文的原始熵，而右侧下方的秘密包括握手上下文，因此可以在没有额外上下文的情况下用于派生工作密钥。请注意，派生Secret的不同调用可能采用不同的Messages参数，即使使用相同的Secret。在0-RTT交换中，使用四个不同的转录本调用派生机密；在仅1-RTT的交换中，它被称为三个不同的转录本。
If a given secret is not available, then the 0-value consisting of a string of Hash.length bytes set to zeros is used. Note that this does not mean skipping rounds, so if PSK is not in use, Early Secret will still be HKDF-Extract(0, 0). For the computation of the binder_key, the label is "ext binder" for external PSKs (those provisioned outside of TLS) and "res binder" for resumption PSKs (those provisioned as the resumption master secret of a previous handshake). The different labels prevent the substitution of one type of PSK for the other.
如果给定的机密不可用，则使用由设置为零的Hash.length字节字符串组成的0值。请注意，这并不意味着跳过回合，所以如果PSK未使用，早期机密仍将是HKDF提取（0，0）。对于binder_密钥的计算，标签是外部PSK的“ext binder”（在TLS之外提供的）和恢复PSK的“res binder”（作为先前握手的恢复主密钥提供的）。不同的标签可防止一种PSK替代另一种PSK。
There are multiple potential Early Secret values, depending on which PSK the server ultimately selects. The client will need to compute one for each potential PSK; if no PSK is selected, it will then need to compute the Early Secret corresponding to the zero PSK.
根据服务器最终选择的PSK，可能存在多个早期机密值。客户需要为每个潜在PSK计算一个；如果未选择PSK，则需要计算对应于零PSK的早期机密。
Once all the values which are to be derived from a given secret have been computed, that secret SHOULD be erased.
一旦计算了从给定秘密中导出的所有值，则应删除该秘密。
Once the handshake is complete, it is possible for either side to update its sending traffic keys using the KeyUpdate handshake message defined in Section 4.6.3. The next generation of traffic keys is computed by generating client_/server_application_traffic_secret_N+1 from client_/server_application_traffic_secret_N as described in this section and then re-deriving the traffic keys as described in Section 7.3.
握手完成后，任何一方都可以使用第4.6.3节中定义的KeyUpdate握手消息更新其发送的通信密钥。计算下一代流量密钥的方法是：根据本节所述的客户机/服务器应用程序-流量-秘密生成客户机/服务器应用程序-流量-秘密，然后根据第7.3节所述重新推导流量密钥。
The next-generation application_traffic_secret is computed as:
下一代应用程序_流量_秘密计算如下：
application_traffic_secret_N+1 = HKDF-Expand-Label(application_traffic_secret_N, "traffic upd", "", Hash.length)
application\u traffic\u secret\N+1=HKDF扩展标签（application\u traffic\u secret\N，“traffic upd”，“”，Hash.length）
Once client_/server_application_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete client_/server_application_traffic_secret_N and its associated traffic keys.
一旦计算了客户端\服务器\应用程序\流量\机密\ N+1及其关联的流量密钥，实现应删除客户端\服务器\应用程序\流量\机密\ N及其关联的流量密钥。
The traffic keying material is generated from the following input values:
流量键控材质由以下输入值生成：
- A secret value
- 秘密价值
- A purpose value indicating the specific value being generated
- 指示生成的特定值的目的值
- The length of the key being generated
- 正在生成的密钥的长度
The traffic keying material is generated from an input traffic secret value using:
使用以下方法从输入的流量秘密值生成流量密钥材料：
[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
[sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length)
[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
[sender]_write_iv = HKDF-Expand-Label(Secret, "iv", "", iv_length)
[sender] denotes the sending side. The value of Secret for each record type is shown in the table below.
[发送方]表示发送方。每种记录类型的Secret值如下表所示。
+-------------------+---------------------------------------+
| Record Type | Secret |
+-------------------+---------------------------------------+
| 0-RTT Application | client_early_traffic_secret |
| | |
| Handshake | [sender]_handshake_traffic_secret |
| | |
| Application Data | [sender]_application_traffic_secret_N |
+-------------------+---------------------------------------+
+-------------------+---------------------------------------+
| Record Type | Secret |
+-------------------+---------------------------------------+
| 0-RTT Application | client_early_traffic_secret |
| | |
| Handshake | [sender]_handshake_traffic_secret |
| | |
| Application Data | [sender]_application_traffic_secret_N |
+-------------------+---------------------------------------+
All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update).
每当底层秘密发生变化时（例如，从握手更改为应用程序数据密钥时或密钥更新时），都会重新计算所有流量密钥材料。
For finite field groups, a conventional Diffie-Hellman [DH76] computation is performed. The negotiated key (Z) is converted to a byte string by encoding in big-endian form and left-padded with zeros up to the size of the prime. This byte string is used as the shared secret in the key schedule as specified above.
对于有限场群，执行常规的Diffie-Hellman[DH76]计算。协商密钥（Z）通过以大端形式编码转换为字节字符串，并用零填充到素数大小。此字节字符串用作密钥计划中的共享密钥，如上所述。
Note that this construction differs from previous versions of TLS which removed leading zeros.
请注意，此构造不同于TLS的早期版本，后者删除了前导零。
For secp256r1, secp384r1, and secp521r1, ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to [IEEE1363] using the ECKAS-DH1 scheme with the identity map as the key derivation function (KDF), so that the shared secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string. Note that this octet string ("Z" in IEEE 1363 terminology) as output by FE2OSP (the Field Element to Octet String Conversion Primitive) has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated.
对于secp256r1、secp384r1和secp521r1，ECDH计算（包括参数和密钥生成以及共享秘密计算）根据[IEEE1363]使用ECKAS-DH1方案执行，身份映射作为密钥派生函数（KDF），因此，共享秘密是ECDH共享秘密椭圆曲线点的x坐标，表示为八位字符串。请注意，FE2OSP（字段元素到八位字节字符串转换原语）输出的八位字节字符串（“IEEE 1363术语中的Z”）对于任何给定字段都具有恒定长度；不得截断此八位字节字符串中的前导零。
(Note that this use of the identity KDF is a technicality. The complete picture is that ECDH is employed with a non-trivial KDF because TLS does not directly use this secret for anything other than for computing other secrets.)
（请注意，标识KDF的使用是一个技术性问题。完整的情况是ECDH与一个非平凡的KDF一起使用，因为TLS不直接将此机密用于计算其他机密以外的任何事情。）
For X25519 and X448, the ECDH calculations are as follows:
对于X25519和X448，ECDH计算如下：
- The public key to put into the KeyShareEntry.key_exchange structure is the result of applying the ECDH scalar multiplication function to the secret key of appropriate length (into scalar input) and the standard public basepoint (into u-coordinate point input).
- 要放入KeyShareEntry.key_交换结构的公钥是将ECDH标量乘法函数应用于适当长度的密钥（标量输入）和标准公共基点（u坐标点输入）的结果。
- The ECDH shared secret is the result of applying the ECDH scalar multiplication function to the secret key (into scalar input) and the peer's public key (into u-coordinate point input). The output is used raw, with no processing.
- ECDH共享密钥是将ECDH标量乘法函数应用于密钥（进入标量输入）和对等方公钥（进入u坐标点输入）的结果。输出是原始的，没有处理。
For these curves, implementations SHOULD use the approach specified in [RFC7748] to calculate the Diffie-Hellman shared secret. Implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in Section 6 of [RFC7748]. If implementors use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of [RFC7748].
对于这些曲线，实现应该使用[RFC7748]中指定的方法来计算Diffie-Hellman共享秘密。如[RFC7748]第6节所述，实现必须检查计算出的Diffie-Hellman共享机密是否为全零值，如果是，则中止。如果实施者使用这些椭圆曲线的替代实现，他们应执行[RFC7748]第7节中规定的附加检查。
[RFC5705] defines keying material exporters for TLS in terms of the TLS pseudorandom function (PRF). This document replaces the PRF with HKDF, thus requiring a new construction. The exporter interface remains the same.
[RFC5705]根据TLS伪随机函数（PRF）定义TLS的键控材质导出器。本文件以HKDF取代PRF，因此需要新的结构。导出器接口保持不变。
The exporter value is computed as:
导出器值的计算公式为：
TLS-Exporter(label, context_value, key_length) =
HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
"exporter", Hash(context_value), key_length)
TLS-Exporter(label, context_value, key_length) =
HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
"exporter", Hash(context_value), key_length)
Where Secret is either the early_exporter_master_secret or the exporter_master_secret. Implementations MUST use the exporter_master_secret unless explicitly specified by the application. The early_exporter_master_secret is defined for use in settings where an exporter is needed for 0-RTT data. A separate interface for the early exporter is RECOMMENDED; this avoids the exporter user accidentally using an early exporter when a regular one is desired or vice versa.
其中Secret是早期导出器主密钥或导出器主密钥。除非应用程序明确指定，否则实现必须使用exporter\u master\u secret。早期导出器主密钥定义用于0-RTT数据需要导出器的设置。建议为早期导出器提供单独的接口；这样可以避免导出器用户在需要常规导出器时意外使用早期导出器，反之亦然。
If no context is provided, the context_value is zero length. Consequently, providing no context computes the same value as providing an empty context. This is a change from previous versions of TLS where an empty context produced a different output than an absent context. As of this document's publication, no allocated exporter label is used both with and without a context. Future specifications MUST NOT define a use of exporters that permit both an empty context and no context with the same label. New uses of exporters SHOULD provide a context in all exporter computations, though the value could be empty.
如果未提供上下文，则上下文_值为零长度。因此，不提供上下文计算的值与提供空上下文计算的值相同。这与以前版本的TLS不同，在TLS中，空上下文产生的输出与不存在的上下文不同。自本文件发布之日起，无论是否使用上下文，均未使用分配的出口商标签。未来的规范不得定义允许使用相同标签的空上下文和无上下文的导出器。导出器的新用途应在所有导出器计算中提供上下文，尽管该值可能为空。
Requirements for the format of exporter labels are defined in Section 4 of [RFC5705].
[RFC5705]第4节规定了出口商标签的格式要求。
As noted in Section 2.3 and Appendix E.5, TLS does not provide inherent replay protections for 0-RTT data. There are two potential threats to be concerned with:
如第2.3节和附录E.5所述，TLS不为0-RTT数据提供固有的重放保护。有两个潜在威胁需要关注：
- Network attackers who mount a replay attack by simply duplicating a flight of 0-RTT data.
- 网络攻击者通过简单复制0-RTT数据的飞行来发起重播攻击。
- Network attackers who take advantage of client retry behavior to arrange for the server to receive multiple copies of an application message. This threat already exists to some extent because clients that value robustness respond to network errors by attempting to retry requests. However, 0-RTT adds an additional dimension for any server system which does not maintain globally consistent server state. Specifically, if a server system has multiple zones where tickets from zone A will not be accepted in zone B, then an attacker can duplicate a ClientHello and early data intended for A to both A and B. At A, the data will be accepted in 0-RTT, but at B the server will reject 0-RTT data and instead force a full handshake. If the attacker blocks the ServerHello from A, then the client will complete the handshake with B and probably retry the request, leading to duplication on the server system as a whole.
- 网络攻击者利用客户端重试行为安排服务器接收应用程序消息的多个副本。这种威胁在某种程度上已经存在，因为重视健壮性的客户端通过尝试重试请求来响应网络错误。但是，0-RTT为任何不维护全局一致服务器状态的服务器系统添加了一个额外维度。具体而言，如果服务器系统有多个区域，其中区域B中不接受来自区域a的票证，则攻击者可以将用于a的ClientHello和早期数据复制到a和B。在a处，数据将以0-RTT方式接受，但在B处，服务器将拒绝0-RTT数据，而是强制进行完全握手。如果攻击者阻止A的ServerHello，则客户端将完成与B的握手，并可能重试该请求，从而导致整个服务器系统上的复制。
The first class of attack can be prevented by sharing state to guarantee that the 0-RTT data is accepted at most once. Servers SHOULD provide that level of replay safety by implementing one of the methods described in this section or by equivalent means. It is understood, however, that due to operational concerns not all deployments will maintain state at that level. Therefore, in normal operation, clients will not know which, if any, of these mechanisms servers actually implement and hence MUST only send early data which they deem safe to be replayed.
第一类攻击可以通过共享状态来防止，以确保0-RTT数据最多接受一次。服务器应通过实施本节所述的方法之一或通过同等方式提供该级别的重播安全性。但可以理解的是，由于运营问题，并非所有部署都将保持该级别的状态。因此，在正常操作中，客户端将不知道服务器实际实现了哪些机制（如果有的话），因此必须只发送他们认为安全的早期数据进行重播。
In addition to the direct effects of replays, there is a class of attacks where even operations normally considered idempotent could be exploited by a large number of replays (timing attacks, resource limit exhaustion and others, as described in Appendix E.5). Those can be mitigated by ensuring that every 0-RTT payload can be replayed only a limited number of times. The server MUST ensure that any instance of it (be it a machine, a thread, or any other entity within the relevant serving infrastructure) would accept 0-RTT for the same 0-RTT handshake at most once; this limits the number of replays to the number of server instances in the deployment. Such a guarantee can be accomplished by locally recording data from recently received ClientHellos and rejecting repeats, or by any other method that
除了重放的直接影响外，还有一类攻击，在这种攻击中，即使是通常被认为是幂等的操作也可能被大量重放利用（定时攻击、资源限制耗尽等，如附录E.5所述）。可以通过确保每个0-RTT有效负载只能重放有限的次数来缓解这些问题。服务器必须确保它的任何实例（无论是机器、线程还是相关服务基础设施中的任何其他实体）最多接受一次相同的0-RTT握手的0-RTT；这将重播次数限制为部署中的服务器实例数。这种保证可以通过本地记录最近收到的ClientHellos的数据并拒绝重复，或者通过任何其他方法来实现
provides the same or a stronger guarantee. The "at most once per server instance" guarantee is a minimum requirement; servers SHOULD limit 0-RTT replays further when feasible.
提供相同或更强的保证。“每个服务器实例最多一次”保证是最低要求；可行时，服务器应进一步限制0-RTT重播。
The second class of attack cannot be prevented at the TLS layer and MUST be dealt with by any application. Note that any application whose clients implement any kind of retry behavior already needs to implement some sort of anti-replay defense.
第二类攻击无法在TLS层预防，必须由任何应用程序处理。请注意，其客户端实现任何类型重试行为的任何应用程序都已经需要实现某种类型的反重播防御。
The simplest form of anti-replay defense is for the server to only allow each session ticket to be used once. For instance, the server can maintain a database of all outstanding valid tickets, deleting each ticket from the database as it is used. If an unknown ticket is provided, the server would then fall back to a full handshake.
最简单的反重播防御形式是服务器只允许每个会话票证使用一次。例如，服务器可以维护一个包含所有未完成有效票证的数据库，在使用时从数据库中删除每个票证。如果提供了一张未知的票据，服务器将返回到完全握手。
If the tickets are not self-contained but rather are database keys, and the corresponding PSKs are deleted upon use, then connections established using PSKs enjoy forward secrecy. This improves security for all 0-RTT data and PSK usage when PSK is used without (EC)DHE.
如果票据不是自包含的，而是数据库密钥，并且在使用时删除相应的PSK，则使用PSK建立的连接享有前向保密性。当PSK在没有（EC）DHE的情况下使用时，这提高了所有0-RTT数据和PSK使用的安全性。
Because this mechanism requires sharing the session database between server nodes in environments with multiple distributed servers, it may be hard to achieve high rates of successful PSK 0-RTT connections when compared to self-encrypted tickets. Unlike session databases, session tickets can successfully do PSK-based session establishment even without consistent storage, though when 0-RTT is allowed they still require consistent storage for anti-replay of 0-RTT data, as detailed in the following section.
由于此机制需要在具有多个分布式服务器的环境中的服务器节点之间共享会话数据库，因此与自加密票据相比，可能很难实现高成功率的PSK 0-RTT连接。与会话数据库不同，即使没有一致的存储，会话票证也可以成功地建立基于PSK的会话，尽管在允许0-RTT的情况下，它们仍然需要一致的存储来防止0-RTT数据的重放，详见下一节。
An alternative form of anti-replay is to record a unique value derived from the ClientHello (generally either the random value or the PSK binder) and reject duplicates. Recording all ClientHellos causes state to grow without bound, but a server can instead record ClientHellos within a given time window and use the "obfuscated_ticket_age" to ensure that tickets aren't reused outside that window.
反重放的另一种形式是记录从ClientHello派生的唯一值（通常是随机值或PSK绑定器），并拒绝重复。记录所有ClientHellos会导致状态增长而不受限制，但服务器可以在给定的时间窗口内记录ClientHellos，并使用“模糊化”来确保票据不会在该窗口外重复使用。
In order to implement this, when a ClientHello is received, the server first verifies the PSK binder as described in Section 4.2.11. It then computes the expected_arrival_time as described in the next section and rejects 0-RTT if it is outside the recording window, falling back to the 1-RTT handshake.
为了实现这一点，当收到ClientHello时，服务器首先按照第4.2.11节所述验证PSK绑定器。然后，如下一节所述，它计算预期的到达时间，如果0-RTT在记录窗口之外，则拒绝0-RTT，返回到1-RTT握手。
If the expected_arrival_time is in the window, then the server checks to see if it has recorded a matching ClientHello. If one is found, it either aborts the handshake with an "illegal_parameter" alert or accepts the PSK but rejects 0-RTT. If no matching ClientHello is found, then it accepts 0-RTT and then stores the ClientHello for as long as the expected_arrival_time is inside the window. Servers MAY also implement data stores with false positives, such as Bloom filters, in which case they MUST respond to apparent replay by rejecting 0-RTT but MUST NOT abort the handshake.
如果预期到达时间在窗口中，则服务器检查是否记录了匹配的ClientHello。如果找到一个，它会使用“非法_参数”警报中止握手，或者接受PSK但拒绝0-RTT。如果未找到匹配的ClientHello，则它接受0-RTT，然后只要预期到达时间在窗口内，就存储ClientHello。服务器还可以实现带有误报的数据存储，例如Bloom过滤器，在这种情况下，它们必须通过拒绝0-RTT来响应明显的重播，但不得中止握手。
The server MUST derive the storage key only from validated sections of the ClientHello. If the ClientHello contains multiple PSK identities, then an attacker can create multiple ClientHellos with different binder values for the less-preferred identity on the assumption that the server will not verify it (as recommended by Section 4.2.11). I.e., if the client sends PSKs A and B but the server prefers A, then the attacker can change the binder for B without affecting the binder for A. If the binder for B is part of the storage key, then this ClientHello will not appear as a duplicate, which will cause the ClientHello to be accepted, and may cause side effects such as replay cache pollution, although any 0-RTT data will not be decryptable because it will use different keys. If the validated binder or the ClientHello.random is used as the storage key, then this attack is not possible.
服务器必须仅从ClientHello的已验证部分派生存储密钥。如果ClientHello包含多个PSK标识，则攻击者可以创建多个ClientHello，这些ClientHello具有不同的绑定值，用于不太首选的标识，前提是服务器不会对其进行验证（如第4.2.11节所建议）。也就是说，如果客户端发送PSK A和B，但服务器更喜欢A，则攻击者可以更改B的活页夹而不影响A的活页夹。如果B的活页夹是存储密钥的一部分，则此ClientHello不会显示为副本，这将导致接受ClientHello，并且可能会导致副作用，例如重播缓存污染，尽管任何0-RTT数据都不可解密，因为它将使用不同的密钥。如果已验证的活页夹或ClientHello.random用作存储密钥，则不可能进行此攻击。
Because this mechanism does not require storing all outstanding tickets, it may be easier to implement in distributed systems with high rates of resumption and 0-RTT, at the cost of potentially weaker anti-replay defense because of the difficulty of reliably storing and retrieving the received ClientHello messages. In many such systems, it is impractical to have globally consistent storage of all the received ClientHellos. In this case, the best anti-replay protection is provided by having a single storage zone be authoritative for a given ticket and refusing 0-RTT for that ticket in any other zone. This approach prevents simple replay by the attacker because only one zone will accept 0-RTT data. A weaker design is to implement separate storage for each zone but allow 0-RTT in any zone. This approach limits the number of replays to once per zone. Application message duplication of course remains possible with either design.
由于该机制不需要存储所有未完成的票据，因此可能更容易在具有高恢复率和0-RTT的分布式系统中实现，但由于难以可靠地存储和检索接收到的ClientHello消息，因此可能会导致较弱的防重放防御。在许多这样的系统中，对所有接收到的ClientHello进行全局一致存储是不切实际的。在这种情况下，最好的防重播保护是通过让单个存储区域对给定的票证具有权威性，并在任何其他区域拒绝该票证的0-RTT。此方法可防止攻击者进行简单的重播，因为只有一个区域将接受0-RTT数据。较弱的设计是为每个区域实现单独的存储，但允许在任何区域中进行0-RTT。这种方法将重播次数限制为每个区域一次。当然，应用程序消息复制在两种设计中都是可能的。
When implementations are freshly started, they SHOULD reject 0-RTT as long as any portion of their recording window overlaps the startup time. Otherwise, they run the risk of accepting replays which were originally sent during that period.
当新启动实现时，只要录制窗口的任何部分与启动时间重叠，就应该拒绝0-RTT。否则，他们就有可能接受最初在此期间发送的重播。
Note: If the client's clock is running much faster than the server's, then a ClientHello may be received that is outside the window in the future, in which case it might be accepted for 1-RTT, causing a client retry, and then acceptable later for 0-RTT. This is another variant of the second form of attack described in Section 8.
注意：如果客户端的时钟运行速度比服务器快得多，那么将来可能会收到窗口外的ClientHello，在这种情况下，它可能会被1-RTT接受，导致客户端重试，然后被0-RTT接受。这是第8节中描述的第二种攻击形式的另一种变体。
Because the ClientHello indicates the time at which the client sent it, it is possible to efficiently determine whether a ClientHello was likely sent reasonably recently and only accept 0-RTT for such a ClientHello, otherwise falling back to a 1-RTT handshake. This is necessary for the ClientHello storage mechanism described in Section 8.2 because otherwise the server needs to store an unlimited number of ClientHellos, and is a useful optimization for self-contained single-use tickets because it allows efficient rejection of ClientHellos which cannot be used for 0-RTT.
因为ClientHello指示客户端发送它的时间，所以可以有效地确定ClientHello是否可能是最近合理地发送的，并且对于这样的ClientHello只接受0-RTT，否则返回到1-RTT握手。这对于第8.2节中描述的ClientHello存储机制是必要的，因为否则服务器需要存储无限数量的ClientHello，并且对于自包含的单次使用票据是有用的优化，因为它允许有效地拒绝不能用于0-RTT的ClientHello。
In order to implement this mechanism, a server needs to store the time that the server generated the session ticket, offset by an estimate of the round-trip time between client and server. I.e.,
为了实现这种机制，服务器需要存储服务器生成会话票证的时间，该时间由客户端和服务器之间的往返时间估计值抵消。即。，
adjusted_creation_time = creation_time + estimated_RTT
调整后的创建时间=创建时间+估计时间
This value can be encoded in the ticket, thus avoiding the need to keep state for each outstanding ticket. The server can determine the client's view of the age of the ticket by subtracting the ticket's "ticket_age_add" value from the "obfuscated_ticket_age" parameter in the client's "pre_shared_key" extension. The server can determine the expected_arrival_time of the ClientHello as:
该值可以在票据中编码，从而避免了为每个未完成票据保留状态的需要。服务器可以通过从客户端“pre_shared_key”扩展名中的“Fuzzated_ticket_age”参数中减去票证的“ticket_age_add”值来确定客户端对票证年龄的看法。服务器可以确定ClientHello的预期到达时间，如下所示：
expected_arrival_time = adjusted_creation_time + clients_ticket_age
预期到达时间=调整后的创建时间+客户端时间
When a new ClientHello is received, the expected_arrival_time is then compared against the current server wall clock time and if they differ by more than a certain amount, 0-RTT is rejected, though the 1-RTT handshake can be allowed to complete.
当接收到新的ClientHello时，将预期的到达时间与当前服务器的挂钟时间进行比较，如果它们之间的差异超过一定程度，则拒绝0-RTT，但允许完成1-RTT握手。
There are several potential sources of error that might cause mismatches between the expected_arrival_time and the measured time. Variations in client and server clock rates are likely to be minimal, though potentially the absolute times may be off by large values. Network propagation delays are the most likely causes of a mismatch in legitimate values for elapsed time. Both the NewSessionTicket and ClientHello messages might be retransmitted and therefore delayed, which might be hidden by TCP. For clients on the Internet, this implies windows on the order of ten seconds to account for errors in clocks and variations in measurements; other deployment scenarios may have different needs. Clock skew distributions are not symmetric, so the optimal tradeoff may involve an asymmetric range of permissible mismatch values.
有几个潜在的误差源可能会导致预期到达时间和测量时间不匹配。客户机和服务器时钟速率的变化可能最小，尽管绝对时间可能会偏离较大的值。网络传播延迟是最有可能导致经过时间的合法值不匹配的原因。NewSessionTicket和ClientHello消息都可能被重新传输并因此延迟，这可能被TCP隐藏。对于互联网上的客户机，这意味着在10秒左右的时间窗口内考虑时钟误差和测量变化；其他部署场景可能有不同的需求。时钟偏差分布不是对称的，因此最佳权衡可能涉及允许的不匹配值的不对称范围。
Note that freshness checking alone is not sufficient to prevent replays because it does not detect them during the error window, which -- depending on bandwidth and system capacity -- could include billions of replays in real-world settings. In addition, this freshness checking is only done at the time the ClientHello is received and not when subsequent early Application Data records are received. After early data is accepted, records may continue to be streamed to the server over a longer time period.
请注意，仅新鲜度检查不足以阻止重播，因为它在错误窗口期间不会检测到它们，而根据带宽和系统容量的不同，在现实世界中可能包括数十亿次重播。此外，此新鲜度检查仅在收到ClientHello时进行，而不是在收到后续早期应用程序数据记录时进行。接受早期数据后，记录可能会在更长的时间内继续流式传输到服务器。
In the absence of an application profile standard specifying otherwise:
如果没有应用程序配置文件标准另有规定：
A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4).
符合TLS的应用程序必须实现TLS_AES_128_GCM_SHA256[GCM]密码套件，并应实现TLS_AES_256_GCM_SHA384[GCM]和TLS_CHACHA20_POLY1305_SHA256[RFC8439]密码套件（见附录B.4）。
A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_rsae_sha256 (for CertificateVerify and certificates), and ecdsa_secp256r1_sha256. A TLS-compliant application MUST support key exchange with secp256r1 (NIST P-256) and SHOULD support key exchange with X25519 [RFC7748].
符合TLS的应用程序必须支持rsa_pkcs1_sha256（用于证书）、rsa_pss_rsae_sha256（用于证书验证和证书）和ecdsa_secp256r1_sha256的数字签名。符合TLS的应用程序必须支持与secp256r1（NIST P-256）的密钥交换，并应支持与X25519[RFC7748]的密钥交换。
In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the following TLS extensions:
在没有应用程序配置文件标准另有规定的情况下，符合TLS的应用程序必须实现以下TLS扩展：
- Supported Versions ("supported_versions"; Section 4.2.1)
- 支持的版本（“支持的版本”；第4.2.1节）
- Cookie ("cookie"; Section 4.2.2)
- 曲奇（“曲奇”；第4.2.2节）
- Signature Algorithms ("signature_algorithms"; Section 4.2.3)
- 签名算法（“签名算法”；第4.2.3节）
- Signature Algorithms Certificate ("signature_algorithms_cert"; Section 4.2.3)
- 签名算法证书（“签名算法证书”；第4.2.3节）
- Negotiated Groups ("supported_groups"; Section 4.2.7)
- 协商小组（“受支持的小组”；第4.2.7节）
- Key Share ("key_share"; Section 4.2.8)
- 关键股份（“关键股份”；第4.2.8节）
- Server Name Indication ("server_name"; Section 3 of [RFC6066])
- 服务器名称指示（[RFC6066]第3节中的“服务器名称”）
All implementations MUST send and use these extensions when offering applicable features:
提供适用功能时，所有实现必须发送并使用这些扩展：
- "supported_versions" is REQUIRED for all ClientHello, ServerHello, and HelloRetryRequest messages.
- 所有ClientHello、ServerHello和HelloRetryRequest消息都需要“受支持的_版本”。
- "signature_algorithms" is REQUIRED for certificate authentication.
- 证书认证需要“签名算法”。
- "supported_groups" is REQUIRED for ClientHello messages using DHE or ECDHE key exchange.
- 使用DHE或ECDHE密钥交换的ClientHello消息需要“受支持的组”。
- "key_share" is REQUIRED for DHE or ECDHE key exchange.
- DHE或ECDHE密钥交换需要“密钥共享”。
- "pre_shared_key" is REQUIRED for PSK key agreement.
- PSK密钥协议需要“预共享密钥”。
- "psk_key_exchange_modes" is REQUIRED for PSK key agreement.
- psk密钥协议需要“psk密钥交换模式”。
A client is considered to be attempting to negotiate using this specification if the ClientHello contains a "supported_versions" extension with 0x0304 contained in its body. Such a ClientHello message MUST meet the following requirements:
如果ClientHello包含一个“supported_versions”扩展，并且其主体中包含0x0304，则认为客户端正在尝试使用此规范进行协商。此类ClientHello消息必须满足以下要求：
- If not containing a "pre_shared_key" extension, it MUST contain both a "signature_algorithms" extension and a "supported_groups" extension.
- 如果不包含“pre_shared_key”扩展，则它必须同时包含“signature_algorithms”扩展和“supported_groups”扩展。
- If containing a "supported_groups" extension, it MUST also contain a "key_share" extension, and vice versa. An empty KeyShare.client_shares vector is permitted.
- 如果包含“受支持的\u组”扩展，则它还必须包含“密钥共享”扩展，反之亦然。允许使用空的KeyShare.client_共享向量。
Servers receiving a ClientHello which does not conform to these requirements MUST abort the handshake with a "missing_extension" alert.
接收不符合这些要求的ClientHello的服务器必须中止握手，并发出“缺少扩展名”警报。
Additionally, all implementations MUST support the use of the "server_name" extension with applications capable of using it. Servers MAY require clients to send a valid "server_name" extension. Servers requiring this extension SHOULD respond to a ClientHello lacking a "server_name" extension by terminating the connection with a "missing_extension" alert.
此外，所有实现都必须支持在能够使用“服务器名称”扩展的应用程序中使用该扩展。服务器可能要求客户端发送有效的“服务器名称”扩展名。需要此扩展的服务器应通过使用“缺少扩展名”警报终止连接来响应缺少“服务器名称”扩展名的ClientHello。
This section describes invariants that TLS endpoints and middleboxes MUST follow. It also applies to earlier versions of TLS.
本节介绍TLS端点和中间盒必须遵循的不变量。它也适用于TLS的早期版本。
TLS is designed to be securely and compatibly extensible. Newer clients or servers, when communicating with newer peers, should negotiate the most preferred common parameters. The TLS handshake provides downgrade protection: Middleboxes passing traffic between a newer client and newer server without terminating TLS should be unable to influence the handshake (see Appendix E.1). At the same time, deployments update at different rates, so a newer client or server MAY continue to support older parameters, which would allow it to interoperate with older endpoints.
TLS设计为安全且兼容可扩展。较新的客户端或服务器在与较新的对等方通信时，应协商最首选的公共参数。TLS握手提供降级保护：在不终止TLS的情况下，在较新客户端和较新服务器之间传递流量的中间盒应无法影响握手（见附录E.1）。同时，部署以不同的速率更新，因此较新的客户端或服务器可能会继续支持较旧的参数，这将允许它与较旧的端点进行互操作。
For this to work, implementations MUST correctly handle extensible fields:
要使其工作，实现必须正确处理可扩展字段：
- A client sending a ClientHello MUST support all parameters advertised in it. Otherwise, the server may fail to interoperate by selecting one of those parameters.
- 发送ClientHello的客户端必须支持其中公布的所有参数。否则，服务器可能无法通过选择这些参数之一进行互操作。
- A server receiving a ClientHello MUST correctly ignore all unrecognized cipher suites, extensions, and other parameters. Otherwise, it may fail to interoperate with newer clients. In TLS 1.3, a client receiving a CertificateRequest or NewSessionTicket MUST also ignore all unrecognized extensions.
- 接收ClientHello的服务器必须正确忽略所有无法识别的密码套件、扩展和其他参数。否则，它可能无法与较新的客户端进行互操作。在TLS 1.3中，接收CertificateRequest或NewSessionTicket的客户端还必须忽略所有无法识别的扩展。
- A middlebox which terminates a TLS connection MUST behave as a compliant TLS server (to the original client), including having a certificate which the client is willing to accept, and also as a compliant TLS client (to the original server), including verifying the original server's certificate. In particular, it MUST generate its own ClientHello containing only parameters it understands, and it MUST generate a fresh ServerHello random value, rather than forwarding the endpoint's value.
- 终止TLS连接的中间盒必须作为兼容的TLS服务器（到原始客户端），包括具有客户端愿意接受的证书，以及作为兼容的TLS客户端（到原始服务器），包括验证原始服务器的证书。特别是，它必须生成自己的ClientHello，其中只包含它理解的参数，并且必须生成一个新的ServerHello随机值，而不是转发端点的值。
Note that TLS's protocol requirements and security analysis only apply to the two connections separately. Safely deploying a TLS terminator requires additional security considerations which are beyond the scope of this document.
请注意，TLS的协议要求和安全性分析仅分别适用于这两个连接。安全部署TLS终结器需要额外的安全注意事项，这超出了本文档的范围。
- A middlebox which forwards ClientHello parameters it does not understand MUST NOT process any messages beyond that ClientHello. It MUST forward all subsequent traffic unmodified. Otherwise, it may fail to interoperate with newer clients and servers.
- 转发它不理解的ClientHello参数的中间盒不得处理超出该ClientHello的任何消息。它必须转发所有未经修改的后续流量。否则，它可能无法与较新的客户端和服务器进行互操作。
Forwarded ClientHellos may contain advertisements for features not supported by the middlebox, so the response may include future TLS additions the middlebox does not recognize. These additions MAY change any message beyond the ClientHello arbitrarily. In particular, the values sent in the ServerHello might change, the ServerHello format might change, and the TLSCiphertext format might change.
转发的ClientHellos可能包含针对中间包不支持的功能的广告，因此响应可能包括中间包无法识别的未来TLS添加。这些添加可以任意更改ClientHello之外的任何消息。特别是，ServerHello中发送的值可能会更改，ServerHello格式可能会更改，TLSCiphertext格式可能会更改。
The design of TLS 1.3 was constrained by widely deployed non-compliant TLS middleboxes (see Appendix D.4); however, it does not relax the invariants. Those middleboxes continue to be non-compliant.
TLS 1.3的设计受到广泛部署的不合规TLS中间盒的限制（见附录D.4）；但是，它不会放松不变量。这些中间包仍然不符合要求。
Security issues are discussed throughout this memo, especially in Appendices C, D, and E.
本备忘录中讨论了安全问题，尤其是附录C、D和E。
This document uses several registries that were originally created in [RFC4346] and updated in [RFC8447]. IANA has updated these to reference this document. The registries and their allocation policies are below:
本文档使用了几个最初在[RFC4346]中创建并在[RFC8447]中更新的注册表。IANA已更新这些文件以参考本文件。登记册及其分配政策如下：
- TLS Cipher Suites registry: values with the first byte in the range 0-254 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 255 (decimal) are reserved for Private Use [RFC8126].
- TLS Cipher Suite注册表：第一个字节在0-254（十进制）范围内的值通过所需规范[RFC8126]分配。第一个字节为255（十进制）的值保留供私人使用[RFC8126]。
IANA has added the cipher suites listed in Appendix B.4 to the registry. The "Value" and "Description" columns are taken from the table. The "DTLS-OK" and "Recommended" columns are both marked as "Y" for each new cipher suite.
IANA已将附录B.4中列出的密码套件添加到注册表中。“值”和“说明”列取自该表。对于每个新密码套件，“DTLS-OK”和“推荐”列都标记为“Y”。
- TLS ContentType registry: Future values are allocated via Standards Action [RFC8126].
- TLS ContentType注册表：未来的值通过标准操作[RFC8126]分配。
- TLS Alerts registry: Future values are allocated via Standards Action [RFC8126]. IANA has populated this registry with the values from Appendix B.2. The "DTLS-OK" column is marked as "Y" for all such values. Values marked as "_RESERVED" have comments describing their previous usage.
- TLS警报注册表：通过标准操作[RFC8126]分配未来值。IANA已使用附录B.2中的值填充此注册表。对于所有此类值，“DTLS-OK”列标记为“Y”。标记为“_RESERVED”的值具有描述其以前用法的注释。
- TLS HandshakeType registry: Future values are allocated via Standards Action [RFC8126]. IANA has updated this registry to rename item 4 from "NewSessionTicket" to "new_session_ticket" and populated this registry with the values from Appendix B.3. The "DTLS-OK" column is marked as "Y" for all such values. Values marked "_RESERVED" have comments describing their previous or temporary usage.
- TLS握手类型注册表：未来的值通过标准操作[RFC8126]分配。IANA已更新此注册表，将项目4从“NewSessionTicket”重命名为“new_session_ticket”，并使用附录B.3中的值填充此注册表。对于所有此类值，“DTLS-OK”列标记为“Y”。标记为“_RESERVED”的值具有描述其以前或临时用法的注释。
This document also uses the TLS ExtensionType Values registry originally created in [RFC4366]. IANA has updated it to reference this document. Changes to the registry follow:
本文档还使用最初在[RFC4366]中创建的TLS ExtensionType值注册表。IANA已将其更新为参考本文件。注册表的更改如下：
- IANA has updated the registration policy as follows:
- IANA已将注册政策更新如下：
Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 255 (decimal) are reserved for Private Use [RFC8126].
第一个字节在0-254（十进制）范围内的值通过所需规范[RFC8126]分配。第一个字节为255（十进制）的值保留供私人使用[RFC8126]。
- IANA has updated this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_cert" extensions with the values defined in this document and the "Recommended" value of "Y".
- IANA已更新此注册表，包括“密钥共享”、“预共享密钥”、“psk密钥交换模式”、“早期数据”、“cookie”、“支持的密钥版本”、“证书颁发机构”、“oid过滤器”、“后握手认证”和“签名算法证书”扩展，扩展值在本文档中定义，且“建议”值为“Y”。
- IANA has updated this registry to include a "TLS 1.3" column which lists the messages in which the extension may appear. This column has been initially populated from the table in Section 4.2, with any extension not listed there marked as "-" to indicate that it is not used by TLS 1.3.
- IANA已更新此注册表，以包含“TLS 1.3”列，其中列出了扩展可能出现的消息。该列最初是根据第4.2节中的表填充的，其中未列出的扩展名标记为“-”，以表示TLS 1.3未使用该列。
This document updates an entry in the TLS Certificate Types registry originally created in [RFC6091] and updated in [RFC8447]. IANA has updated the entry for value 1 to have the name "OpenPGP_RESERVED", "Recommended" value "N", and comment "Used in TLS versions prior to 1.3."
本文档更新最初在[RFC6091]中创建并在[RFC8447]中更新的TLS证书类型注册表中的条目。IANA已经更新了值1的条目，名称为“OpenPGP_保留”、“推荐”值为“N”，注释为“在1.3之前的TLS版本中使用”
This document updates an entry in the TLS Certificate Status Types registry originally created in [RFC6961]. IANA has updated the entry for value 2 to have the name "ocsp_multi_RESERVED" and comment "Used in TLS versions prior to 1.3".
本文档更新最初在[RFC6961]中创建的TLS证书状态类型注册表中的条目。IANA已将值2的条目更新为名称“ocsp_multi_RESERVED”和注释“用于1.3之前的TLS版本”。
This document updates two entries in the TLS Supported Groups registry (created under a different name by [RFC4492]; now maintained by [RFC8422]) and updated by [RFC7919] and [RFC8447]. The entries for values 29 and 30 (x25519 and x448) have been updated to also refer to this document.
本文档更新了TLS支持组注册表中的两个条目（由[RFC4492]以不同的名称创建；现在由[RFC8422]维护），并由[RFC7919]和[RFC8447]更新。值29和30（x25519和x448）的条目已更新，也可参考本文档。
In addition, this document defines two new registries that are maintained by IANA:
此外，本文件定义了IANA维护的两个新登记处：
- TLS SignatureScheme registry: Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required [RFC8126]. Values with the first byte 254 or 255 (decimal) are reserved for Private Use [RFC8126]. Values with the first byte in the range 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backward compatibility. This registry has a "Recommended" column. The registry has been initially populated with the values described in Section 4.2.3. The following values are marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, rsa_pss_pss_sha512, and ed25519. The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N transition.
- TLS SignatureScheme注册表：第一个字节在0-253（十进制）范围内的值通过所需规范分配[RFC8126]。第一个字节为254或255（十进制）的值保留供私人使用[RFC8126]。当前未分配的第一个字节在0-6范围内或第二个字节在0-3范围内的值保留为向后兼容。此注册表有一个“推荐”列。注册表最初已填充第4.2.3节中所述的值。以下值标记为“推荐值”：ecdsa_secp256r1_sha256、ecdsa_secp384r1_sha384、rsa_pss_rsae_sha256、rsa_pss_rsae_sha384、rsa_pss_rsae sha512、rsa_pss_pss_sha256、rsa_pss_pss_sha384、rsa_pss_pss_sha512和ed25519。除非明确要求，“推荐”列的值为“N”，添加“推荐”值为“Y”的值需要标准操作[RFC8126]。Y->N转换需要IESG批准。
- TLS PskKeyExchangeMode registry: Values in the range 0-253 (decimal) are assigned via Specification Required [RFC8126]. The values 254 and 255 (decimal) are reserved for Private Use [RFC8126]. This registry has a "Recommended" column. The registry has been initially populated with psk_ke (0) and psk_dhe_ke (1). Both are marked as "Recommended". The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action [RFC8126]. IESG Approval is REQUIRED for a Y->N transition.
- TLS PskKeyExchangeMode注册表：0-253（十进制）范围内的值通过所需规范[RFC8126]分配。值254和255（十进制）保留供私人使用[RFC8126]。此注册表有一个“推荐”列。注册表最初已填充psk_ke（0）和psk_dhe_ke（1）。两者都标记为“推荐”。除非明确要求，“推荐”列的值为“N”，添加“推荐”值为“Y”的值需要标准操作[RFC8126]。Y->N转换需要IESG批准。
[DH76] Diffie, W. and M. Hellman, "New directions in cryptography", IEEE Transactions on Information Theory, Vol. 22 No. 6, pp. 644-654, DOI 10.1109/TIT.1976.1055638, November 1976.
[DH76]Diffie，W.和M.Hellman，“密码学的新方向”，IEEE信息论学报，第22卷第6期，第644-654页，DOI 10.1109/TIT.1976.1055638，1976年11月。
[ECDSA] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI ANS X9.62-2005, November 2005.
[ECDSA]美国国家标准协会，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI ANS X9.62-2005，2005年11月。
[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007.
[GCM]Dworkin，M.“分组密码操作模式的建议：Galois/计数器模式（GCM）和GMAC”，NIST特别出版物800-38D，DOI 10.6028/NIST.SP.800-38D，2007年11月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，DOI 10.17487/RFC2104，1997年2月<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.
[RFC5116]McGrew，D.“认证加密的接口和算法”，RFC 5116，DOI 10.17487/RFC5116，2008年1月<https://www.rfc-editor.org/info/rfc5116>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<https://www.rfc-editor.org/info/rfc5280>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5705]Rescorla，E.“传输层安全（TLS）关键材料导出器”，RFC 5705，DOI 10.17487/RFC5705，2010年3月<https://www.rfc-editor.org/info/rfc5705>.
[RFC5756] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Updates for RSAES-OAEP and RSASSA-PSS Algorithm Parameters", RFC 5756, DOI 10.17487/RFC5756, January 2010, <https://www.rfc-editor.org/info/rfc5756>.
[RFC5756]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“RSAES-OAEP和RSASSA-PSS算法参数的更新”，RFC 5756，DOI 10.17487/RFC5756，2010年1月<https://www.rfc-editor.org/info/rfc5756>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.
[RFC5869]Krawczyk，H.和P.Eronen，“基于HMAC的提取和扩展密钥派生函数（HKDF）”，RFC 5869，DOI 10.17487/RFC5869，2010年5月<https://www.rfc-editor.org/info/rfc5869>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<https://www.rfc-editor.org/info/rfc6066>.
[RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, <https://www.rfc-editor.org/info/rfc6655>.
[RFC6655]McGrew，D.和D.Bailey，“用于传输层安全（TLS）的AES-CCM密码套件”，RFC 6655，DOI 10.17487/RFC6655，2012年7月<https://www.rfc-editor.org/info/rfc6655>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 6960，DOI 10.17487/RFC6960，2013年6月<https://www.rfc-editor.org/info/rfc6960>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <https://www.rfc-editor.org/info/rfc6961>.
[RFC6961]Pettersen，Y，“传输层安全性（TLS）多证书状态请求扩展”，RFC 6961，DOI 10.17487/RFC69611913年6月<https://www.rfc-editor.org/info/rfc6961>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/info/rfc6962>.
[RFC6962]Laurie，B.，Langley，A.和E.Kasper，“证书透明度”，RFC 6962，DOI 10.17487/RFC6962，2013年6月<https://www.rfc-editor.org/info/rfc6962>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC6979]Pornin，T，“数字签名算法（DSA）和椭圆曲线数字签名算法（ECDSA）的确定性使用”，RFC 6979，DOI 10.17487/RFC6979，2013年8月<https://www.rfc-editor.org/info/rfc6979>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7301]Friedl，S.，Popov，A.，Langley，A.，和E.Stephan，“传输层安全（TLS）应用层协议协商扩展”，RFC 7301，DOI 10.17487/RFC7301，2014年7月<https://www.rfc-editor.org/info/rfc7301>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015, <https://www.rfc-editor.org/info/rfc7507>.
[RFC7507]Moeller，B.和A.Langley，“用于防止协议降级攻击的TLS回退信令密码套件值（SCSV）”，RFC 7507，DOI 10.17487/RFC7507，2015年4月<https://www.rfc-editor.org/info/rfc7507>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748]兰利，A.，汉堡，M.和S.特纳，“安全的椭圆曲线”，RFC 7748，DOI 10.17487/RFC7748，2016年1月<https://www.rfc-editor.org/info/rfc7748>.
[RFC7919] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS)", RFC 7919, DOI 10.17487/RFC7919, August 2016, <https://www.rfc-editor.org/info/rfc7919>.
[RFC7919]Gillmor，D.“传输层安全（TLS）的协商有限域Diffie-Hellman瞬时参数”，RFC 7919，DOI 10.17487/RFC7919，2016年8月<https://www.rfc-editor.org/info/rfc7919>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, "PKCS #1: RSA Cryptography Specifications Version 2.2", RFC 8017, DOI 10.17487/RFC8017, November 2016, <https://www.rfc-editor.org/info/rfc8017>.
[RFC8017]Moriarty，K.，Ed.，Kaliski，B.，Jonsson，J.，和A.Rusch，“PKCS#1:RSA加密规范版本2.2”，RFC 8017，DOI 10.17487/RFC8017，2016年11月<https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8032]Josefsson，S.和I.Liusvaara，“爱德华兹曲线数字签名算法（EdDSA）”，RFC 8032，DOI 10.17487/RFC8032，2017年1月<https://www.rfc-editor.org/info/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, <https://www.rfc-editor.org/info/rfc8439>.
[RFC8439]Nir，Y.和A.Langley，“IETF协议的ChaCha20和Poly1305”，RFC 8439，DOI 10.17487/RFC8439，2018年6月<https://www.rfc-editor.org/info/rfc8439>.
[SHS] Dang, Q., "Secure Hash Standard (SHS)", National Institute of Standards and Technology report, DOI 10.6028/NIST.FIPS.180-4, August 2015.
[SHS]Dang，Q.，“安全哈希标准（SHS）”，国家标准与技术研究所报告，DOI 10.6028/NIST.FIPS.180-42015年8月。
[X690] ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2015, November 2015.
[X690]ITU-T，“信息技术——ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ISO/IEC 8825-1:2015，2015年11月。
[AEAD-LIMITS] Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", August 2017, <http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[AEAD-LIMITS]Luykx，A.和K.Paterson，“TLS中认证加密使用的限制”，2017年8月<http://www.isg.rhul.ac.uk/~kp/TLS AEbounds.pdf>。
[BBFGKZ16] Bhargavan, K., Brzuska, C., Fournet, C., Green, M., Kohlweiss, M., and S. Zanella-Beguelin, "Downgrade Resilience in Key-Exchange Protocols", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2016.37, May 2016.
[BBFGKZ16]Bhargavan，K.，Brzuska，C.，Fournet，C.，Green，M.，Kohlweiss，M.，和S.Zanella Beguelin，“密钥交换协议中的降级弹性”，IEEE安全和隐私研讨会论文集（圣何塞），DOI 10.1109/SP.2016.37，2016年5月。
[BBK17] Bhargavan, K., Blanchet, B., and N. Kobeissi, "Verified Models and Reference Implementations for the TLS 1.3 Standard Candidate", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2017.26, May 2017.
[BBK17]Bhargavan，K.，Blanchet，B.，和N.Kobeissi，“TLS 1.3候选标准的验证模型和参考实施”，IEEE安全和隐私研讨会论文集（圣何塞），DOI 10.1109/SP.2017.26，2017年5月。
[BDFKPPRSZZ16] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Kohlweiss, M., Pan, J., Protzenko, J., Rastogi, A., Swamy, N., Zanella-Beguelin, S., and J. Zinzindohoue, "Implementing and Proving the TLS 1.3 Record Layer", Proceedings of IEEE Symposium on Security and Privacy (San Jose), May 2017, <https://eprint.iacr.org/2016/1178>.
[BDFKPRSZ16]Bhargavan，K.，Delignat-Lavaud，A.，Fournet，C.，Kohlweiss，M.，Pan，J.，Protzenko，J.，Rastogi，A.，Swamy，N.，Zanella Beguelin，S.，和J.Zinzindohoue，“实施和证明TLS 1.3记录层”，IEEE安全和隐私研讨会论文集（圣何塞），2017年5月<https://eprint.iacr.org/2016/1178>.
[Ben17a] Benjamin, D., "Presentation before the TLS WG at IETF 100", November 2017, <https://datatracker.ietf.org/meeting/100/materials/ slides-100-tls-sessa-tls13/>.
[Ben17a]Benjamin，D.，“在IETF 100上TLS工作组的演示”，2017年11月<https://datatracker.ietf.org/meeting/100/materials/ 幻灯片-100-tls-sessa-tls13/>。
[Ben17b] Benjamin, D., "Additional TLS 1.3 results from Chrome", message to the TLS mailing list, 18 December 2017, <https://www.ietf.org/mail-archive/web/tls/current/ msg25168.html>.
[Ben17b]Benjamin，D.，“Chrome带来的额外TLS 1.3结果”，给TLS邮件列表的信息，2017年12月18日<https://www.ietf.org/mail-archive/web/tls/current/ msg25168.html>。
[Blei98] Bleichenbacher, D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1", Proceedings of CRYPTO '98, 1998.
[Blei98]Bleichenbacher，D.，“针对基于RSA加密标准PKCS#1的协议的选择密文攻击”，CRYPTO'981998年论文集。
[BMMRT15] Badertscher, C., Matt, C., Maurer, U., Rogaway, P., and B. Tackmann, "Augmented Secure Channels and the Goal of the TLS 1.3 Record Layer", ProvSec 2015, September 2015, <https://eprint.iacr.org/2015/394>.
[BMMRT15]Badertscher，C.，Matt，C.，Maurer，U.，Rogaway，P.，和B.Tackmann，“增强的安全通道和TLS 1.3记录层的目标”，ProvSec 2015，2015年9月<https://eprint.iacr.org/2015/394>.
[BT16] Bellare, M. and B. Tackmann, "The Multi-User Security of Authenticated Encryption: AES-GCM in TLS 1.3", Proceedings of CRYPTO 2016, July 2016, <https://eprint.iacr.org/2016/564>.
[BT16]Bellare，M.和B.Tackmann，“认证加密的多用户安全性：TLS 1.3中的AES-GCM”，《2016年加密会议录》，2016年7月<https://eprint.iacr.org/2016/564>.
[CCG16] Cohn-Gordon, K., Cremers, C., and L. Garratt, "On Post-compromise Security", IEEE Computer Security Foundations Symposium, DOI 10.1109/CSF.2016.19, July 2015.
[CCG16]Cohn Gordon，K.，Cremers，C.，和L.Garratt，“关于妥协后安全”，IEEE计算机安全基金会研讨会，DOI 10.1109/CSF.2016.19，2015年7月。
[CHECKOWAY] Checkoway, S., Maskiewicz, J., Garman, C., Fried, J., Cohney, S., Green, M., Heninger, N., Weinmann, R., Rescorla, E., and H. Shacham, "A Systematic Analysis of the Juniper Dual EC Incident", Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security - CCS '16, DOI 10.1145/2976749.2978395, October 2016.
[CHECKOWAY]CHECKOWAY，S.，Maskiewicz，J.，Garman，C.，Fried，J.，Cohney，S.，Green，M.，Heninger，N.，Weinmann，R.，Rescorla，E.，和H.Shacham，“Juniper Dual EC事件的系统分析”，2016年ACM SIGSAC计算机和通信安全会议记录，2016年10月，DOI 10.1145/2976749.2978395。
[CHHSV17] Cremers, C., Horvat, M., Hoyland, J., Scott, S., and T. van der Merwe, "Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18", message to the TLS mailing list, 10 February 2017, <https://www.ietf.org/ mail-archive/web/tls/current/msg22382.html>.
[CHHSV17]Cremers，C.，Horvat，M.，Hoyland，J.，Scott，S.，和T.van der Merwe，“笨拙的握手：第18版握手后模式下客户端/服务器对客户端身份验证的看法可能不匹配”，发送给TLS邮件列表的信息，2017年2月10日<https://www.ietf.org/ 邮件存档/web/tls/current/msg22382.html>。
[CHSV16] Cremers, C., Horvat, M., Scott, S., and T. van der Merwe, "Automated Analysis and Verification of TLS 1.3: 0-RTT, Resumption and Delayed Authentication", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2016.35, May 2016, <https://ieeexplore.ieee.org/document/7546518/>.
[CHSV16]Cremers，C.，Horvat，M.，Scott，S.，和T.van der Merwe，“TLS 1.3:0-RTT的自动分析和验证，恢复和延迟认证”，IEEE安全和隐私研讨会论文集（圣何塞），DOI 10.1109/SP.2016.352016年5月<https://ieeexplore.ieee.org/document/7546518/>.
[CK01] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels", Proceedings of Eurocrypt 2001, DOI 10.1007/3-540-44987-6_28, April 2001.
[CK01]Canetti，R.和H.Krawczyk，“密钥交换协议及其用于构建安全通道的分析”，Eurocrypt 2001年论文集，DOI 10.1007/3-540-44987-6湜，2001年4月。
[CLINIC] Miller, B., Huang, L., Joseph, A., and J. Tygar, "I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis", Privacy Enhancing Technologies, pp. 143-163, DOI 10.1007/978-3-319-08506-7_8, 2014.
[诊所]Miller，B.，Huang，L.，Joseph，A.，和J.Tygar，“我知道你为什么去诊所：HTTPS流量分析的风险和实现”，隐私增强技术，第143-163页，DOI 10.1007/978-3-319-08506-7_8，2014。
[DFGS15] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, "A Cryptographic Analysis of the TLS 1.3 Handshake Protocol Candidates", Proceedings of ACM CCS 2015, October 2015, <https://eprint.iacr.org/2015/914>.
[DFGS15]Dowling，B.，Fischlin，M.，Guenther，F.，和D.Stebila，“TLS 1.3握手协议候选协议的密码分析”，ACM CCS 2015年会议记录，2015年10月<https://eprint.iacr.org/2015/914>.
[DFGS16] Dowling, B., Fischlin, M., Guenther, F., and D. Stebila, "A Cryptographic Analysis of the TLS 1.3 Full and Pre-shared Key Handshake Protocol", TRON 2016, February 2016, <https://eprint.iacr.org/2016/081>.
[DFGS16]Dowling，B.，Fischlin，M.，Guenther，F.，和D.Stebila，“TLS 1.3完整和预共享密钥握手协议的密码分析”，TRON 2016，2016年2月<https://eprint.iacr.org/2016/081>.
[DOW92] Diffie, W., van Oorschot, P., and M. Wiener, "Authentication and authenticated key exchanges", Designs, Codes and Cryptography, DOI 10.1007/BF00124891, June 1992.
[DOW92]Diffie，W.，van Oorschot，P.，和M.Wiener，“认证和认证密钥交换”，设计、代码和密码学，DOI 10.1007/BF00124891，1992年6月。
[DSS] National Institute of Standards and Technology, U.S. Department of Commerce, "Digital Signature Standard (DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013.
[DSS]美国商务部国家标准与技术研究所，“数字签名标准（DSS）”，NIST FIPS PUB 186-4，DOI 10.6028/NIST.FIPS.186-42013年7月。
[FG17] Fischlin, M. and F. Guenther, "Replay Attacks on Zero Round-Trip Time: The Case of the TLS 1.3 Handshake Candidates", Proceedings of EuroS&P 2017, April 2017, <https://eprint.iacr.org/2017/082>.
[FG17]Fischlin，M.和F.Guenther，“零往返时间的重放攻击：TLS 1.3握手候选案例”，《2017年欧洲及太平洋会议录》，2017年4月<https://eprint.iacr.org/2017/082>.
[FGSW16] Fischlin, M., Guenther, F., Schmidt, B., and B. Warinschi, "Key Confirmation in Key Exchange: A Formal Treatment and Implications for TLS 1.3", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2016.34, May 2016, <https://ieeexplore.ieee.org/document/7546517/>.
[FGSW16]Fischlin，M.，Guenther，F.，Schmidt，B.，和B.Warinschi，“密钥交换中的密钥确认：TLS 1.3的正式处理和影响”，IEEE安全和隐私研讨会论文集（圣何塞），DOI 10.1109/SP.2016.342016年5月<https://ieeexplore.ieee.org/document/7546517/>.
[FW15] Weimer, F., "Factoring RSA Keys With TLS Perfect Forward Secrecy", September 2015.
[FW15]Weimer，F.，“利用TLS完美前向保密性分解RSA密钥”，2015年9月。
[HCJC16] Husak, M., Cermak, M., Jirsik, T., and P. Celeda, "HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting", EURASIP Journal on Information Security, Vol. 2016, DOI 10.1186/s13635-016-0030-7, February 2016.
[HCJC16]Husak，M.，Cermak，M.，Jirsik，T.，和P.Celeda，“使用被动SSL/TLS指纹的HTTPS流量分析和客户端识别”，EURASIP信息安全杂志，2016年第卷，DOI 10.1186/s13635-016-0030-7，2016年2月。
[HGFS15] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, "Prying Open Pandora's Box: KCI Attacks against TLS", Proceedings of USENIX Workshop on Offensive Technologies, August 2015.
[HGFS15]Hlauschek，C.，Gruber，M.，Fankhauser，F.，和C.Schanes，“撬开潘多拉魔盒：KCI对TLS的攻击”，USENIX攻击性技术研讨会论文集，2015年8月。
[IEEE1363] IEEE, "IEEE Standard Specifications for Public Key Cryptography", IEEE Std. 1363-2000, DOI 10.1109/IEEESTD.2000.92292.
[IEEE1363]IEEE，“IEEE公钥加密标准规范”，IEEE标准1363-2000，DOI 10.1109/IEEESTD.2000.92292。
[JSS15] Jager, T., Schwenk, J., and J. Somorovsky, "On the Security of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption", Proceedings of ACM CCS 2015, DOI 10.1145/2810103.2813657, October 2015, <https://www.nds.rub.de/media/nds/ veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf>.
[JSS15]Jager，T.，Schwenk，J.，和J.Somorovsky，“关于TLS 1.3和QUIC针对PKCS#1 v1.5加密弱点的安全性”，ACM CCS 2015年会议记录，DOI 10.1145/2810103.2813657，2015年10月<https://www.nds.rub.de/media/nds/ veroeffentlichungen/2015/08/21/TLS13quicatacks.pdf>。
[KEYAGREEMENT] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography", National Institute of Standards and Technology, DOI 10.6028/NIST.SP.800-56Ar3, April 2018.
[KEYAGREEMENT]Barker，E.，Chen，L.，Roginsky，A.，Vassilev，A.，和R.Davis，“使用离散对数加密的成对密钥建立方案的建议”，国家标准与技术研究所，DOI 10.6028/NIST.SP.800-56Ar3，2018年4月。
[Kraw10] Krawczyk, H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme", Proceedings of CRYPTO 2010, August 2010, <https://eprint.iacr.org/2010/264>.
[Kraw10]Krawczyk，H.，“密码提取和密钥推导：HKDF方案”，《2010年密码会议录》，2010年8月<https://eprint.iacr.org/2010/264>.
[Kraw16] Krawczyk, H., "A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3", Proceedings of ACM CCS 2016, October 2016, <https://eprint.iacr.org/2016/711>.
[Kraw16]Krawczyk，H.，“用于密钥交换的单边到相互身份验证编译器（在TLS 1.3中应用于客户端身份验证），《2016年ACM CCS会议录》，2016年10月<https://eprint.iacr.org/2016/711>.
[KW16] Krawczyk, H. and H. Wee, "The OPTLS Protocol and TLS 1.3", Proceedings of EuroS&P 2016, March 2016, <https://eprint.iacr.org/2015/978>.
[KW16]Krawczyk，H.和H.Wee，“OPTLS协议和TLS 1.3”，2016年3月《2016年欧洲及太平洋会议记录》<https://eprint.iacr.org/2015/978>.
[LXZFH16] Li, X., Xu, J., Zhang, Z., Feng, D., and H. Hu, "Multiple Handshakes Security of TLS 1.3 Candidates", Proceedings of IEEE Symposium on Security and Privacy (San Jose), DOI 10.1109/SP.2016.36, May 2016, <https://ieeexplore.ieee.org/document/7546519/>.
[LXZFH16]Li，X.，Xu，J.，Zhang，Z.，Feng，D.，和H.Hu，“TLS 1.3候选者的多次握手安全”，IEEE安全与隐私研讨会论文集（圣何塞），DOI 10.1109/SP.2016.362016年5月<https://ieeexplore.ieee.org/document/7546519/>.
[Mac17] MacCarthaigh, C., "Security Review of TLS1.3 0-RTT", March 2017, <https://github.com/tlswg/tls13-spec/ issues/1001>.
[Mac17]MacCarthaigh，C.，“TLS1.3 0-RTT的安全审查”，2017年3月<https://github.com/tlswg/tls13-spec/ 问题/1001>。
[PS18] Patton, C. and T. Shrimpton, "Partially specified channels: The TLS 1.3 record layer without elision", 2018, <https://eprint.iacr.org/2018/634>.
[PS18]Patton，C.和T.Shrimpton，“部分指定通道：不省略的TLS 1.3记录层”，2018年<https://eprint.iacr.org/2018/634>.
[PSK-FINISHED] Scott, S., Cremers, C., Horvat, M., and T. van der Merwe, "Revision 10: possible attack if client authentication is allowed during PSK", message to the TLS mailing list, 31 October 2015, <https://www.ietf.org/ mail-archive/web/tls/current/msg18215.html>.
[PSK-FINISHED]Scott，S.，Cremers，C.，Horvat，M.，和T.van der Merwe，“第10版：PSK期间如果允许客户端身份验证，则可能发生攻击”，发送给TLS邮件列表的消息，2015年10月31日<https://www.ietf.org/ 邮件存档/web/tls/current/msg18215.html>。
[REKEY] Abdalla, M. and M. Bellare, "Increasing the Lifetime of a Key: A Comparative Analysis of the Security of Re-keying Techniques", ASIACRYPT 2000, DOI 10.1007/3-540-44448-3_42, October 2000.
[REKEY]Abdalla，M.和M.Bellare，“增加密钥的使用寿命：密钥更新技术安全性的比较分析”，ASIACRYPT 2000，DOI 10.1007/3-540-44448-342，2000年10月。
[Res17a] Rescorla, E., "Preliminary data on Firefox TLS 1.3 Middlebox experiment", message to the TLS mailing list, 5 December 2017, <https://www.ietf.org/ mail-archive/web/tls/current/msg25091.html>.
[Res17a]Rescorla，E.，“Firefox TLS 1.3中间包实验的初步数据”，发送给TLS邮件列表的信息，2017年12月5日<https://www.ietf.org/ 邮件存档/web/tls/current/msg25091.html>。
[Res17b] Rescorla, E., "More compatibility measurement results", message to the TLS mailing list, 22 December 2017, <https://www.ietf.org/mail-archive/web/tls/current/ msg25179.html>.
[Res17b]Rescorla，E.，“更多兼容性测量结果”，给TLS邮件列表的信息，2017年12月22日<https://www.ietf.org/mail-archive/web/tls/current/ msg25179.html>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552]Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，DOI 10.17487/RFC3552，2003年7月<https://www.rfc-editor.org/info/rfc3552>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<https://www.rfc-editor.org/info/rfc4086>.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，DOI 10.17487/RFC4346，2006年4月<https://www.rfc-editor.org/info/rfc4346>.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, DOI 10.17487/RFC4366, April 2006, <https://www.rfc-editor.org/info/rfc4366>.
[RFC4366]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，DOI 10.17487/RFC4366，2006年4月<https://www.rfc-editor.org/info/rfc4366>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, DOI 10.17487/RFC4492, May 2006, <https://www.rfc-editor.org/info/rfc4492>.
[RFC4492]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线密码（ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006年5月<https://www.rfc-editor.org/info/rfc4492>.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008年1月<https://www.rfc-editor.org/info/rfc5077>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, <https://www.rfc-editor.org/info/rfc5764>.
[RFC5764]McGrew，D.和E.Rescorla，“为安全实时传输协议（SRTP）建立密钥的数据报传输层安全（DTLS）扩展”，RFC 5764，DOI 10.17487/RFC5764，2010年5月<https://www.rfc-editor.org/info/rfc5764>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010, <https://www.rfc-editor.org/info/rfc5929>.
[RFC5929]Altman，J.，Williams，N.和L.Zhu，“TLS的通道绑定”，RFC 5929，DOI 10.17487/RFC5929，2010年7月<https://www.rfc-editor.org/info/rfc5929>.
[RFC6091] Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 6091, DOI 10.17487/RFC6091, February 2011, <https://www.rfc-editor.org/info/rfc6091>.
[RFC6091]Mavrogiannopoulos，N.和D.Gillmor，“使用OpenPGP密钥进行传输层安全（TLS）认证”，RFC 6091，DOI 10.17487/RFC60912011年2月<https://www.rfc-editor.org/info/rfc6091>.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, DOI 10.17487/RFC6101, August 2011, <https://www.rfc-editor.org/info/rfc6101>.
[RFC6101]Freier，A.，Karlton，P.，和P.Kocher，“安全套接字层（SSL）协议版本3.0”，RFC 6101，DOI 10.17487/RFC6101，2011年8月<https://www.rfc-editor.org/info/rfc6101>.
[RFC6176] Turner, S. and T. Polk, "Prohibiting Secure Sockets Layer (SSL) Version 2.0", RFC 6176, DOI 10.17487/RFC6176, March 2011, <https://www.rfc-editor.org/info/rfc6176>.
[RFC6176]Turner，S.和T.Polk，“禁止安全套接字层（SSL）2.0版”，RFC 6176，DOI 10.17487/RFC6176，2011年3月<https://www.rfc-editor.org/info/rfc6176>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<https://www.rfc-editor.org/info/rfc6347>.
[RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension", RFC 6520, DOI 10.17487/RFC6520, February 2012, <https://www.rfc-editor.org/info/rfc6520>.
[RFC6520]Seggelmann，R.，Tuexen，M.和M.Williams，“传输层安全性（TLS）和数据报传输层安全性（DTLS）心跳扩展”，RFC 6520，DOI 10.17487/RFC6520，2012年2月<https://www.rfc-editor.org/info/rfc6520>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<https://www.rfc-editor.org/info/rfc7230>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7250]Wouters，P.，Ed.，Tschofenig，H.，Ed.，Gilmore，J.，Weiler，S.，和T.Kivinen，“在传输层安全性（TLS）和数据报传输层安全性（DTLS）中使用原始公钥”，RFC 7250，DOI 10.17487/RFC72502014年6月<https://www.rfc-editor.org/info/rfc7250>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <https://www.rfc-editor.org/info/rfc7465>.
[RFC7465]Popov，A.，“禁止RC4密码套件”，RFC 7465，DOI 10.17487/RFC7465，2015年2月<https://www.rfc-editor.org/info/rfc7465>.
[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, DOI 10.17487/RFC7568, June 2015, <https://www.rfc-editor.org/info/rfc7568>.
[RFC7568]Barnes，R.，Thomson，M.，Pironti，A.，和A.Langley，“不推荐安全套接字层版本3.0”，RFC 7568，DOI 10.17487/RFC7568，2015年6月<https://www.rfc-editor.org/info/rfc7568>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A., Langley, A., and M. Ray, "Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension", RFC 7627, DOI 10.17487/RFC7627, September 2015, <https://www.rfc-editor.org/info/rfc7627>.
[RFC7627]Bhargavan，K.，Ed.，Delignat Lavaud，A.，Pironti，A.，Langley，A.，和M.Ray，“传输层安全（TLS）会话哈希和扩展主秘密扩展”，RFC 7627，DOI 10.17487/RFC7627，2015年9月<https://www.rfc-editor.org/info/rfc7627>.
[RFC7685] Langley, A., "A Transport Layer Security (TLS) ClientHello Padding Extension", RFC 7685, DOI 10.17487/RFC7685, October 2015, <https://www.rfc-editor.org/info/rfc7685>.
[RFC7685]Langley，A.“传输层安全（TLS）ClientHello填充扩展”，RFC 7685，DOI 10.17487/RFC7685，2015年10月<https://www.rfc-editor.org/info/rfc7685>.
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-editor.org/info/rfc7924>.
[RFC7924]Santesson，S.和H.Tschofenig，“传输层安全（TLS）缓存信息扩展”，RFC 7924DOI 10.17487/RFC79242016年7月<https://www.rfc-editor.org/info/rfc7924>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
[RFC8305]Schinazi，D.和T.Pauly，“快乐眼球第2版：使用并发实现更好的连接”，RFC 8305，DOI 10.17487/RFC8305，2017年12月<https://www.rfc-editor.org/info/rfc8305>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.
[RFC8422]Nir，Y.，Josefsson，S.，和M.Pegourie Gonnard，“传输层安全（TLS）版本1.2及更早版本的椭圆曲线密码（ECC）套件”，RFC 8422，DOI 10.17487/RFC8422，2018年8月<https://www.rfc-editor.org/info/rfc8422>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.
[RFC8447]Salowey，J.和S.Turner，“TLS和DTL的IANA注册更新”，RFC 8447，DOI 10.17487/RFC8447，2018年8月<https://www.rfc-editor.org/info/rfc8447>.
[RFC8449] Thomson, M., "Record Size Limit Extension for TLS", RFC 8449, DOI 10.17487/RFC8449, August 2018, <https://www.rfc-editor.org/info/rfc8449>.
[RFC8449]Thomson，M.，“TLS的记录尺寸限制扩展”，RFC 8449，DOI 10.17487/RFC8449，2018年8月<https://www.rfc-editor.org/info/rfc8449>.
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, Vol. 21 No. 2, pp. 120-126, DOI 10.1145/359340.359342, February 1978.
[RSA]Rivest，R.，Shamir，A.，和L.Adleman，“获取数字签名和公钥密码系统的方法”，《ACM通信》，第21卷第2期，第120-126页，DOI 10.1145/359340.359342，1978年2月。
[SIGMA] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols", Proceedings of CRYPTO 2003, DOI 10.1007/978-3-540-45146-4_24, August 2003.
[SIGMA]Krawczyk，H.，“SIGMA：认证Diffie-Hellman的‘符号和MAc’方法及其在IKE协议中的使用”，《加密程序2003》，DOI 10.1007/978-3-540-45146-4_，2003年8月24日。
[SLOTH] Bhargavan, K. and G. Leurent, "Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH", Network and Distributed System Security Symposium (NDSS 2016), DOI 10.14722/ndss.2016.23418, February 2016.
[SLOTH]Bhargavan，K.和G.Leurent，“转录本冲突攻击：破坏TLS、IKE和SSH中的身份验证”，网络和分布式系统安全研讨会（NDSS 2016），DOI 10.14722/NDSS.2016.2341818，2016年2月。
[SSL2] Hickman, K., "The SSL Protocol", February 1995.
[SSL2]Hickman，K.，“SSL协议”，1995年2月。
[TIMING] Boneh, D. and D. Brumley, "Remote Timing Attacks Are Practical", USENIX Security Symposium, August 2003.
[定时]Boneh，D.和D.Brumley，“远程定时攻击是切实可行的”，USENIX安全研讨会，2003年8月。
[TLS13-TRACES] Thomson, M., "Example Handshake Traces for TLS 1.3", Work in Progress, draft-ietf-tls-tls13-vectors-06, July 2018.
[TLS13-TRACES]Thomson，M.，“TLS 1.3的握手跟踪示例”，正在进行的工作，草稿-ietf-TLS-TLS13-vectors-062018年7月。
[X501] ITU-T, "Information Technology - Open Systems Interconnection - The Directory: Models", ITU-T X.501, October 2016, <https://www.itu.int/rec/T-REC-X.501/en>.
[X501]ITU-T，“信息技术-开放系统互连-目录：模型”，ITU-T X.5012016年10月<https://www.itu.int/rec/T-REC-X.501/en>.
This appendix provides a summary of the legal state transitions for the client and server handshakes. State names (in all capitals, e.g., START) have no formal meaning but are provided for ease of comprehension. Actions which are taken only in certain circumstances are indicated in []. The notation "K_{send,recv} = foo" means "set the send/recv key to the given key".
本附录概述了客户端和服务器握手的法律状态转换。州名称（所有大写字母，如START）没有正式含义，但为便于理解而提供。只有在某些情况下才采取的行动见[]。符号“K_{send，recv}=foo”表示“将send/recv键设置为给定键”。
START <----+
Send ClientHello | | Recv HelloRetryRequest
[K_send = early data] | |
v |
/ WAIT_SH ----+
| | Recv ServerHello
| | K_recv = handshake
Can | V
send | WAIT_EE
early | | Recv EncryptedExtensions
data | +--------+--------+
| Using | | Using certificate
| PSK | v
| | WAIT_CERT_CR
| | Recv | | Recv CertificateRequest
| | Certificate | v
| | | WAIT_CERT
| | | | Recv Certificate
| | v v
| | WAIT_CV
| | | Recv CertificateVerify
| +> WAIT_FINISHED <+
| | Recv Finished
\ | [Send EndOfEarlyData]
| K_send = handshake
| [Send Certificate [+ CertificateVerify]]
Can send | Send Finished
app data --> | K_send = K_recv = application
after here v
CONNECTED
START <----+
Send ClientHello | | Recv HelloRetryRequest
[K_send = early data] | |
v |
/ WAIT_SH ----+
| | Recv ServerHello
| | K_recv = handshake
Can | V
send | WAIT_EE
early | | Recv EncryptedExtensions
data | +--------+--------+
| Using | | Using certificate
| PSK | v
| | WAIT_CERT_CR
| | Recv | | Recv CertificateRequest
| | Certificate | v
| | | WAIT_CERT
| | | | Recv Certificate
| | v v
| | WAIT_CV
| | | Recv CertificateVerify
| +> WAIT_FINISHED <+
| | Recv Finished
\ | [Send EndOfEarlyData]
| K_send = handshake
| [Send Certificate [+ CertificateVerify]]
Can send | Send Finished
app data --> | K_send = K_recv = application
after here v
CONNECTED
Note that with the transitions as shown above, clients may send alerts that derive from post-ServerHello messages in the clear or with the early data keys. If clients need to send such alerts, they SHOULD first rekey to the handshake keys if possible.
请注意，通过如上所示的转换，客户机可以发送来自clear或使用早期数据键的post-ServerHello消息的警报。如果客户端需要发送此类警报，则应首先在可能的情况下重新输入握手键。
START <-----+
Recv ClientHello | | Send HelloRetryRequest
v |
RECVD_CH ----+
| Select parameters
v
NEGOTIATED
| Send ServerHello
| K_send = handshake
| Send EncryptedExtensions
| [Send CertificateRequest]
Can send | [Send Certificate + CertificateVerify]
app data | Send Finished
after --> | K_send = application
here +--------+--------+
No 0-RTT | | 0-RTT
| |
K_recv = handshake | | K_recv = early data
[Skip decrypt errors] | +------> WAIT_EOED -+
| | Recv | | Recv EndOfEarlyData
| | early data | | K_recv = handshake
| +------------+ |
| |
+> WAIT_FLIGHT2 <--------+
|
+--------+--------+
No auth | | Client auth
| |
| v
| WAIT_CERT
| Recv | | Recv Certificate
| empty | v
| Certificate | WAIT_CV
| | | Recv
| v | CertificateVerify
+-> WAIT_FINISHED <---+
| Recv Finished
| K_recv = application
v
CONNECTED
START <-----+
Recv ClientHello | | Send HelloRetryRequest
v |
RECVD_CH ----+
| Select parameters
v
NEGOTIATED
| Send ServerHello
| K_send = handshake
| Send EncryptedExtensions
| [Send CertificateRequest]
Can send | [Send Certificate + CertificateVerify]
app data | Send Finished
after --> | K_send = application
here +--------+--------+
No 0-RTT | | 0-RTT
| |
K_recv = handshake | | K_recv = early data
[Skip decrypt errors] | +------> WAIT_EOED -+
| | Recv | | Recv EndOfEarlyData
| | early data | | K_recv = handshake
| +------------+ |
| |
+> WAIT_FLIGHT2 <--------+
|
+--------+--------+
No auth | | Client auth
| |
| v
| WAIT_CERT
| Recv | | Recv Certificate
| empty | v
| Certificate | WAIT_CV
| | | Recv
| v | CertificateVerify
+-> WAIT_FINISHED <---+
| Recv Finished
| K_recv = application
v
CONNECTED
This appendix provides the normative protocol types and the definitions for constants. Values listed as "_RESERVED" were used in previous versions of TLS and are listed here for completeness. TLS 1.3 implementations MUST NOT send them but might receive them from older TLS implementations.
本附录提供了规范协议类型和常数定义。列为“_RESERVED”的值在TLS的早期版本中使用，为完整起见，此处列出。TLS 1.3实现不能发送它们，但可以从较旧的TLS实现接收它们。
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
heartbeat(24), /* RFC 6520 */
(255)
} ContentType;
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
heartbeat(24), /* RFC 6520 */
(255)
} ContentType;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
ContentType type;
ProtocolVersion legacy_record_version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
opaque content[TLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} TLSInnerPlaintext;
struct {
opaque content[TLSPlaintext.length];
ContentType type;
uint8 zeros[length_of_padding];
} TLSInnerPlaintext;
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
enum { warning(1), fatal(2), (255) } AlertLevel;
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure_RESERVED(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
no_renegotiation_RESERVED(100),
missing_extension(109),
unsupported_extension(110),
certificate_unobtainable_RESERVED(111),
unrecognized_name(112),
bad_certificate_status_response(113),
bad_certificate_hash_value_RESERVED(114),
unknown_psk_identity(115),
certificate_required(116),
no_application_protocol(120),
(255)
} AlertDescription;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure_RESERVED(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
inappropriate_fallback(86),
user_canceled(90),
no_renegotiation_RESERVED(100),
missing_extension(109),
unsupported_extension(110),
certificate_unobtainable_RESERVED(111),
unrecognized_name(112),
bad_certificate_status_response(113),
bad_certificate_hash_value_RESERVED(114),
unknown_psk_identity(115),
certificate_required(116),
no_application_protocol(120),
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
enum {
hello_request_RESERVED(0),
client_hello(1),
server_hello(2),
hello_verify_request_RESERVED(3),
new_session_ticket(4),
end_of_early_data(5),
hello_retry_request_RESERVED(6),
encrypted_extensions(8),
certificate(11),
server_key_exchange_RESERVED(12),
certificate_request(13),
server_hello_done_RESERVED(14),
certificate_verify(15),
client_key_exchange_RESERVED(16),
finished(20),
certificate_url_RESERVED(21),
certificate_status_RESERVED(22),
supplemental_data_RESERVED(23),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
enum {
hello_request_RESERVED(0),
client_hello(1),
server_hello(2),
hello_verify_request_RESERVED(3),
new_session_ticket(4),
end_of_early_data(5),
hello_retry_request_RESERVED(6),
encrypted_extensions(8),
certificate(11),
server_key_exchange_RESERVED(12),
certificate_request(13),
server_hello_done_RESERVED(14),
certificate_verify(15),
client_key_exchange_RESERVED(16),
finished(20),
certificate_url_RESERVED(21),
certificate_status_RESERVED(22),
supplemental_data_RESERVED(23),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;
uint16 ProtocolVersion;
opaque Random[32];
uint16 ProtocolVersion;
opaque Random[32];
uint8 CipherSuite[2]; /* Cryptographic suite selector */
uint8 CipherSuite[2]; /* Cryptographic suite selector */
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id<0..32>;
CipherSuite cipher_suites<2..2^16-2>;
opaque legacy_compression_methods<1..2^8-1>;
Extension extensions<8..2^16-1>;
} ClientHello;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello;
struct {
ProtocolVersion legacy_version = 0x0303; /* TLS v1.2 */
Random random;
opaque legacy_session_id_echo<0..32>;
CipherSuite cipher_suite;
uint8 legacy_compression_method = 0;
Extension extensions<6..2^16-1>;
} ServerHello;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
RESERVED(40), /* Used but never
assigned */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
RESERVED(46), /* Used but never
assigned */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
enum {
server_name(0), /* RFC 6066 */
max_fragment_length(1), /* RFC 6066 */
status_request(5), /* RFC 6066 */
supported_groups(10), /* RFC 8422, 7919 */
signature_algorithms(13), /* RFC 8446 */
use_srtp(14), /* RFC 5764 */
heartbeat(15), /* RFC 6520 */
application_layer_protocol_negotiation(16), /* RFC 7301 */
signed_certificate_timestamp(18), /* RFC 6962 */
client_certificate_type(19), /* RFC 7250 */
server_certificate_type(20), /* RFC 7250 */
padding(21), /* RFC 7685 */
RESERVED(40), /* Used but never
assigned */
pre_shared_key(41), /* RFC 8446 */
early_data(42), /* RFC 8446 */
supported_versions(43), /* RFC 8446 */
cookie(44), /* RFC 8446 */
psk_key_exchange_modes(45), /* RFC 8446 */
RESERVED(46), /* Used but never
assigned */
certificate_authorities(47), /* RFC 8446 */
oid_filters(48), /* RFC 8446 */
post_handshake_auth(49), /* RFC 8446 */
signature_algorithms_cert(50), /* RFC 8446 */
key_share(51), /* RFC 8446 */
(65535)
} ExtensionType;
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
struct {
NamedGroup group;
opaque key_exchange<1..2^16-1>;
} KeyShareEntry;
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
struct {
KeyShareEntry client_shares<0..2^16-1>;
} KeyShareClientHello;
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
struct {
NamedGroup selected_group;
} KeyShareHelloRetryRequest;
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
struct {
KeyShareEntry server_share;
} KeyShareServerHello;
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
struct {
uint8 legacy_form = 4;
opaque X[coordinate_length];
opaque Y[coordinate_length];
} UncompressedPointRepresentation;
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;
struct {
PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes;
struct {
PskKeyExchangeMode ke_modes<1..255>;
} PskKeyExchangeModes;
struct {} Empty;
struct {} Empty;
struct {
select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty;
case encrypted_extensions: Empty;
};
} EarlyDataIndication;
struct {
select (Handshake.msg_type) {
case new_session_ticket: uint32 max_early_data_size;
case client_hello: Empty;
case encrypted_extensions: Empty;
};
} EarlyDataIndication;
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
} PskIdentity;
struct {
opaque identity<1..2^16-1>;
uint32 obfuscated_ticket_age;
} PskIdentity;
opaque PskBinderEntry<32..255>;
opaque PskBinderEntry<32..255>;
struct {
PskIdentity identities<7..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;
struct {
PskIdentity identities<7..2^16-1>;
PskBinderEntry binders<33..2^16-1>;
} OfferedPsks;
struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;
struct {
select (Handshake.msg_type) {
case client_hello: OfferedPsks;
case server_hello: uint16 selected_identity;
};
} PreSharedKeyExtension;
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
struct {
select (Handshake.msg_type) {
case client_hello:
ProtocolVersion versions<2..254>;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
case server_hello: /* and HelloRetryRequest */
ProtocolVersion selected_version;
};
} SupportedVersions;
struct {
opaque cookie<1..2^16-1>;
} Cookie;
struct {
opaque cookie<1..2^16-1>;
} Cookie;
enum {
/* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601),
enum {
/* RSASSA-PKCS1-v1_5 algorithms */
rsa_pkcs1_sha256(0x0401),
rsa_pkcs1_sha384(0x0501),
rsa_pkcs1_sha512(0x0601),
/* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
/* ECDSA algorithms */
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
/* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_rsae_sha256(0x0804),
rsa_pss_rsae_sha384(0x0805),
rsa_pss_rsae_sha512(0x0806),
/* RSASSA-PSS algorithms with public key OID rsaEncryption */
rsa_pss_rsae_sha256(0x0804),
rsa_pss_rsae_sha384(0x0805),
rsa_pss_rsae_sha512(0x0806),
/* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),
/* EdDSA algorithms */
ed25519(0x0807),
ed448(0x0808),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* RSASSA-PSS algorithms with public key OID RSASSA-PSS */
rsa_pss_pss_sha256(0x0809),
rsa_pss_pss_sha384(0x080a),
rsa_pss_pss_sha512(0x080b),
/* Legacy algorithms */
rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203),
/* Legacy algorithms */
rsa_pkcs1_sha1(0x0201),
ecdsa_sha1(0x0203),
/* Reserved Code Points */
obsolete_RESERVED(0x0000..0x0200),
dsa_sha1_RESERVED(0x0202),
obsolete_RESERVED(0x0204..0x0400),
dsa_sha256_RESERVED(0x0402),
obsolete_RESERVED(0x0404..0x0500),
dsa_sha384_RESERVED(0x0502),
obsolete_RESERVED(0x0504..0x0600),
dsa_sha512_RESERVED(0x0602),
obsolete_RESERVED(0x0604..0x06FF),
private_use(0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
/* Reserved Code Points */
obsolete_RESERVED(0x0000..0x0200),
dsa_sha1_RESERVED(0x0202),
obsolete_RESERVED(0x0204..0x0400),
dsa_sha256_RESERVED(0x0402),
obsolete_RESERVED(0x0404..0x0500),
dsa_sha384_RESERVED(0x0502),
obsolete_RESERVED(0x0504..0x0600),
dsa_sha512_RESERVED(0x0602),
obsolete_RESERVED(0x0604..0x06FF),
private_use(0xFE00..0xFFFF),
(0xFFFF)
} SignatureScheme;
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
struct {
SignatureScheme supported_signature_algorithms<2..2^16-2>;
} SignatureSchemeList;
enum {
unallocated_RESERVED(0x0000),
enum {
unallocated_RESERVED(0x0000),
/* Elliptic Curve Groups (ECDHE) */
obsolete_RESERVED(0x0001..0x0016),
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
obsolete_RESERVED(0x001A..0x001C),
x25519(0x001D), x448(0x001E),
/* Elliptic Curve Groups (ECDHE) */
obsolete_RESERVED(0x0001..0x0016),
secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
obsolete_RESERVED(0x001A..0x001C),
x25519(0x001D), x448(0x001E),
/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Finite Field Groups (DHE) */
ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
ffdhe6144(0x0103), ffdhe8192(0x0104),
/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
obsolete_RESERVED(0xFF01..0xFF02),
(0xFFFF)
} NamedGroup;
/* Reserved Code Points */
ffdhe_private_use(0x01FC..0x01FF),
ecdhe_private_use(0xFE00..0xFEFF),
obsolete_RESERVED(0xFF01..0xFF02),
(0xFFFF)
} NamedGroup;
struct {
NamedGroup named_group_list<2..2^16-1>;
} NamedGroupList;
struct {
NamedGroup named_group_list<2..2^16-1>;
} NamedGroupList;
Values within "obsolete_RESERVED" ranges are used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 implementations. The obsolete curves have various known/theoretical weaknesses or have had very little usage, in some cases only due to unintentional server configuration issues. They are no longer considered appropriate for general use and should be assumed to be potentially unsafe. The set of curves specified here is sufficient for interoperability with all currently deployed and properly configured TLS implementations.
“过时_保留”范围内的值在TLS的早期版本中使用，TLS 1.3实现不得提供或协商。过时的曲线有各种已知/理论上的弱点，或者只有很少的使用，在某些情况下只是由于无意中的服务器配置问题。它们不再被视为适用于一般用途，应被视为具有潜在的不安全性。此处指定的曲线集足以与当前部署和正确配置的所有TLS实现实现互操作。
opaque DistinguishedName<1..2^16-1>;
opaque DistinguishedName<1..2^16-1>;
struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;
struct {
DistinguishedName authorities<3..2^16-1>;
} CertificateAuthoritiesExtension;
struct {
opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} OIDFilter;
struct {
opaque certificate_extension_oid<1..2^8-1>;
opaque certificate_extension_values<0..2^16-1>;
} OIDFilter;
struct {
OIDFilter filters<0..2^16-1>;
} OIDFilterExtension;
struct {
OIDFilter filters<0..2^16-1>;
} OIDFilterExtension;
struct {} PostHandshakeAuth;
struct {} PostHandshakeAuth;
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
struct {
Extension extensions<0..2^16-1>;
} EncryptedExtensions;
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
struct {
opaque certificate_request_context<0..2^8-1>;
Extension extensions<2..2^16-1>;
} CertificateRequest;
enum {
X509(0),
OpenPGP_RESERVED(1),
RawPublicKey(2),
(255)
} CertificateType;
enum {
X509(0),
OpenPGP_RESERVED(1),
RawPublicKey(2),
(255)
} CertificateType;
struct {
select (certificate_type) {
case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
struct {
select (certificate_type) {
case RawPublicKey:
/* From RFC 7250 ASN.1_subjectPublicKeyInfo */
opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
struct {
SignatureScheme algorithm;
opaque signature<0..2^16-1>;
} CertificateVerify;
struct {
opaque verify_data[Hash.length];
} Finished;
struct {
opaque verify_data[Hash.length];
} Finished;
struct {
uint32 ticket_lifetime;
uint32 ticket_age_add;
opaque ticket_nonce<0..255>;
opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>;
} NewSessionTicket;
struct {
uint32 ticket_lifetime;
uint32 ticket_age_add;
opaque ticket_nonce<0..255>;
opaque ticket<1..2^16-1>;
Extension extensions<0..2^16-2>;
} NewSessionTicket;
struct {} EndOfEarlyData;
struct {} EndOfEarlyData;
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
enum {
update_not_requested(0), update_requested(1), (255)
} KeyUpdateRequest;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
struct {
KeyUpdateRequest request_update;
} KeyUpdate;
A symmetric cipher suite defines the pair of the AEAD algorithm and hash algorithm to be used with HKDF. Cipher suite names follow the naming convention:
对称密码套件定义了与HKDF一起使用的AEAD算法和哈希算法对。密码套件名称遵循命名约定：
CipherSuite TLS_AEAD_HASH = VALUE;
CipherSuite TLS_AEAD_哈希=值；
+-----------+------------------------------------------------+
| Component | Contents |
+-----------+------------------------------------------------+
| TLS | The string "TLS" |
| | |
| AEAD | The AEAD algorithm used for record protection |
| | |
| HASH | The hash algorithm used with HKDF |
| | |
| VALUE | The two-byte ID assigned for this cipher suite |
+-----------+------------------------------------------------+
+-----------+------------------------------------------------+
| Component | Contents |
+-----------+------------------------------------------------+
| TLS | The string "TLS" |
| | |
| AEAD | The AEAD algorithm used for record protection |
| | |
| HASH | The hash algorithm used with HKDF |
| | |
| VALUE | The two-byte ID assigned for this cipher suite |
+-----------+------------------------------------------------+
This specification defines the following cipher suites for use with TLS 1.3.
本规范定义了以下用于TLS 1.3的密码套件。
+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+
+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+
The corresponding AEAD algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_AES_128_CCM are defined in [RFC5116]. AEAD_CHACHA20_POLY1305 is defined in [RFC8439]. AEAD_AES_128_CCM_8 is defined in [RFC6655]. The corresponding hash algorithms are defined in [SHS].
[RFC5116]中定义了相应的AEAD算法AEAD_AES_128_GCM、AEAD_AES_256_GCM和AEAD_AES_128_CCM。[RFC8439]中定义了AEAD_CHACHA20_POLY1305。[RFC6655]中定义了AEAD_AES_128_CCM_8。[SHS]中定义了相应的哈希算法。
Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2. Similarly, cipher suites for TLS 1.2 and lower cannot be used with TLS 1.3.
虽然TLS 1.3使用与TLS早期版本相同的密码套件空间，但TLS 1.3密码套件的定义不同，仅指定对称密码，不能用于TLS 1.2。同样，TLS 1.2及更低版本的密码套件不能与TLS 1.3一起使用。
New cipher suite values are assigned by IANA as described in Section 11.
新的密码套件值由IANA分配，如第11节所述。
The TLS protocol cannot prevent many common security mistakes. This appendix provides several recommendations to assist implementors. [TLS13-TRACES] provides test vectors for TLS 1.3 handshakes.
TLS协议无法防止许多常见的安全错误。本附录提供了一些建议，以帮助实施者。[TLS13-TRACES]为TLS 1.3握手提供测试向量。
TLS requires a cryptographically secure pseudorandom number generator (CSPRNG). In most cases, the operating system provides an appropriate facility such as /dev/urandom, which should be used absent other (e.g., performance) concerns. It is RECOMMENDED to use an existing CSPRNG implementation in preference to crafting a new one. Many adequate cryptographic libraries are already available under favorable license terms. Should those prove unsatisfactory, [RFC4086] provides guidance on the generation of random values.
TLS需要一个加密安全的伪随机数生成器（CSPRNG）。在大多数情况下，操作系统提供了一个适当的工具，如/dev/uradom，应该在没有其他（如性能）问题的情况下使用它。建议使用现有的CSPRNG实现，而不是制作新的CSPRNG实现。根据有利的许可条款，许多适当的加密库已经可用。如果证明不符合要求，[RFC4086]提供了生成随机值的指导。
TLS uses random values (1) in public protocol fields such as the public Random values in the ClientHello and ServerHello and (2) to generate keying material. With a properly functioning CSPRNG, this does not present a security problem, as it is not feasible to determine the CSPRNG state from its output. However, with a broken CSPRNG, it may be possible for an attacker to use the public output to determine the CSPRNG internal state and thereby predict the keying material, as documented in [CHECKOWAY]. Implementations can provide extra security against this form of attack by using separate CSPRNGs to generate public and private values.
TLS使用公共协议字段中的随机值（1），如ClientHello和ServerHello中的公共随机值，以及（2）生成密钥材料。对于正常运行的CSPRNG，这并不存在安全问题，因为从其输出确定CSPRNG状态是不可行的。但是，对于损坏的CSPRNG，攻击者可能会使用公共输出来确定CSPRNG内部状态，从而预测键控材料，如[CHECKOWAY]中所述。通过使用单独的CSPRNG生成公共和私有值，实现可以针对这种形式的攻击提供额外的安全性。
Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Absent a specific indication from an application profile, certificates should always be verified to ensure proper signing by a trusted certificate authority (CA). The selection and addition of trust anchors should be done very carefully. Users should be able to view information about the certificate and trust anchor. Applications SHOULD also enforce minimum and maximum key sizes. For example, certification paths containing keys or signatures weaker than 2048-bit RSA or 224-bit ECDSA are not appropriate for secure applications.
实现负责验证证书的完整性，通常应支持证书撤销消息。如果应用程序配置文件中没有特定指示，则应始终验证证书，以确保受信任的证书颁发机构（CA）进行正确签名。信任锚的选择和添加应该非常小心。用户应该能够查看有关证书和信任锚的信息。应用程序还应强制执行最小和最大密钥大小。例如，包含弱于2048位RSA或224位ECDSA的密钥或签名的认证路径不适用于安全应用程序。
Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand and have been a source of interoperability and security problems. Many of these areas have been clarified in this document, but this appendix contains a short list of the most important things that require special attention from implementors.
实施经验表明，早期TLS规范的某些部分不容易理解，并且一直是互操作性和安全问题的根源。这些领域中的许多已经在本文档中阐明，但本附录包含了需要实施者特别注意的最重要事项的简短列表。
TLS protocol issues:
TLS协议问题：
- Do you correctly handle handshake messages that are fragmented to multiple TLS records (see Section 5.1)? Do you correctly handle corner cases like a ClientHello that is split into several small fragments? Do you fragment handshake messages that exceed the maximum fragment size? In particular, the Certificate and CertificateRequest handshake messages can be large enough to require fragmentation.
- 您是否正确处理分段为多个TLS记录的握手消息（参见第5.1节）？你是否正确地处理像ClientHello那样被分成几个小碎片的角落案例？是否对超过最大片段大小的握手消息进行分段？特别是，证书和CertificateRequest握手消息可能大到需要分段。
- Do you ignore the TLS record layer version number in all unencrypted TLS records (see Appendix D)?
- 是否忽略所有未加密TLS记录中的TLS记录层版本号（见附录D）？
- Have you ensured that all support for SSL, RC4, EXPORT ciphers, and MD5 (via the "signature_algorithms" extension) is completely removed from all possible configurations that support TLS 1.3 or later, and that attempts to use these obsolete capabilities fail correctly (see Appendix D)?
- 您是否已确保从支持TLS 1.3或更高版本的所有可能配置中完全删除对SSL、RC4、导出密码和MD5（通过“签名算法”扩展）的所有支持，并且尝试正确使用这些过时功能失败（参见附录D）？
- Do you handle TLS extensions in ClientHellos correctly, including unknown extensions?
- 您是否正确处理ClientHello中的TLS扩展，包括未知扩展？
- When the server has requested a client certificate but no suitable certificate is available, do you correctly send an empty Certificate message, instead of omitting the whole message (see Section 4.4.2)?
- 当服务器已请求客户端证书，但没有合适的证书可用时，您是否正确地发送空证书消息，而不是忽略整个消息（请参阅第4.4.2节）？
- When processing the plaintext fragment produced by AEAD-Decrypt and scanning from the end for the ContentType, do you avoid scanning past the start of the cleartext in the event that the peer has sent a malformed plaintext of all zeros?
- 在处理AEAD Decrypt生成的明文片段并从末尾扫描ContentType时，如果对等方发送了一个格式错误的全零明文，您是否避免扫描到明文开头之后？
- Do you properly ignore unrecognized cipher suites (Section 4.1.2), hello extensions (Section 4.2), named groups (Section 4.2.7), key shares (Section 4.2.8), supported versions (Section 4.2.1), and signature algorithms (Section 4.2.3) in the ClientHello?
- 您是否正确地忽略了ClientHello中无法识别的密码套件（第4.1.2节）、hello扩展（第4.2.2节）、命名组（第4.2.7节）、密钥共享（第4.2.8节）、支持的版本（第4.2.1节）和签名算法（第4.2.3节）？
- As a server, do you send a HelloRetryRequest to clients which support a compatible (EC)DHE group but do not predict it in the "key_share" extension? As a client, do you correctly handle a HelloRetryRequest from the server?
- 作为服务器，您是否向支持兼容（EC）DHE组但未在“密钥共享”扩展中预测该组的客户端发送HelloRetryRequest？作为客户机，您是否正确处理来自服务器的HelloRetryRequest？
Cryptographic details:
加密详细信息：
- What countermeasures do you use to prevent timing attacks [TIMING]?
- 你用什么对策来防止定时攻击[定时]？
- When using Diffie-Hellman key exchange, do you correctly preserve leading zero bytes in the negotiated key (see Section 7.4.1)?
- 使用Diffie-Hellman密钥交换时，您是否正确保留协商密钥中的前导零字节（参见第7.4.1节）？
- Does your TLS client check that the Diffie-Hellman parameters sent by the server are acceptable (see Section 4.2.8.1)?
- 您的TLS客户端是否检查服务器发送的Diffie-Hellman参数是否可接受（请参阅第4.2.8.1节）？
- Do you use a strong and, most importantly, properly seeded random number generator (see Appendix C.1) when generating Diffie-Hellman private values, the ECDSA "k" parameter, and other security-critical values? It is RECOMMENDED that implementations implement "deterministic ECDSA" as specified in [RFC6979].
- 在生成Diffie-Hellman私有值、ECDSA“k”参数和其他安全关键值时，您是否使用了一个强大且最重要的、正确播种的随机数生成器（见附录C.1）？建议实现[RFC6979]中规定的“确定性ECDSA”。
- Do you zero-pad Diffie-Hellman public key values and shared secrets to the group size (see Section 4.2.8.1 and Section 7.4.1)?
- 您是否将Diffie-Hellman公钥值和共享机密归零到组大小（参见第4.2.8.1节和第7.4.1节）？
- Do you verify signatures after making them, to protect against RSA-CRT key leaks [FW15]?
- 您是否在制作签名后验证签名，以防止RSA-CRT密钥泄漏[FW15]？
Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of a ticket allows passive observers to correlate different connections. Servers that issue tickets SHOULD offer at least as many tickets as the number of connections that a client might use; for example, a web browser using HTTP/1.1 [RFC7230] might open six connections to a server. Servers SHOULD issue new tickets with every connection. This ensures that clients are always able to use a new ticket when creating a new connection.
客户端不应为多个连接重复使用票据。票据的重用允许被动观察者关联不同的连接。发出票证的服务器应提供至少与客户端可能使用的连接数相同的票证；例如，使用HTTP/1.1[RFC7230]的web浏览器可能会打开到服务器的六个连接。服务器应在每次连接时发出新的票证。这确保了客户端在创建新连接时始终能够使用新的票证。
Previous versions of TLS offered explicitly unauthenticated cipher suites based on anonymous Diffie-Hellman. These modes have been deprecated in TLS 1.3. However, it is still possible to negotiate parameters that do not provide verifiable server authentication by several methods, including:
TLS的早期版本提供了基于匿名Diffie-Hellman的明确未经验证的密码套件。这些模式在TLS 1.3中已被弃用。但是，仍然可以通过多种方法协商不提供可验证服务器身份验证的参数，包括：
- Raw public keys [RFC7250].
- 原始公钥[RFC7250]。
- Using a public key contained in a certificate but without validation of the certificate chain or any of its contents.
- 使用证书中包含的公钥，但未验证证书链或其任何内容。
Either technique used alone is vulnerable to man-in-the-middle attacks and therefore unsafe for general use. However, it is also possible to bind such connections to an external authentication mechanism via out-of-band validation of the server's public key, trust on first use, or a mechanism such as channel bindings (though the channel bindings described in [RFC5929] are not defined for TLS 1.3). If no such mechanism is used, then the connection has no protection against active man-in-the-middle attack; applications MUST NOT use TLS in such a way absent explicit configuration or a specific application profile.
单独使用的任何一种技术都容易受到中间人攻击，因此一般使用都不安全。但是，也可以通过服务器公钥的带外验证、首次使用时的信任或通道绑定等机制将此类连接绑定到外部身份验证机制（尽管[RFC5929]中描述的通道绑定未针对TLS 1.3定义）。如果没有使用这样的机制，那么连接就无法抵御主动中间人攻击；如果没有明确的配置或特定的应用程序配置文件，应用程序不得以这种方式使用TLS。
The TLS protocol provides a built-in mechanism for version negotiation between endpoints potentially supporting different versions of TLS.
TLS协议为可能支持不同版本TLS的端点之间的版本协商提供了内置机制。
TLS 1.x and SSL 3.0 use compatible ClientHello messages. Servers can also handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible and there is at least one protocol version supported by both the client and the server.
TLS 1.x和SSL 3.0使用兼容的ClientHello消息。只要ClientHello格式保持兼容并且客户端和服务器至少支持一个协议版本，服务器还可以处理尝试使用TLS未来版本的客户端。
Prior versions of TLS used the record layer version number (TLSPlaintext.legacy_record_version and TLSCiphertext.legacy_record_version) for various purposes. As of TLS 1.3, this field is deprecated. The value of TLSPlaintext.legacy_record_version MUST be ignored by all implementations. The value of TLSCiphertext.legacy_record_version is included in the additional data for deprotection but MAY otherwise be ignored or MAY be validated to match the fixed constant value. Version negotiation is performed using only the handshake versions (ClientHello.legacy_version and ServerHello.legacy_version, as well as the ClientHello, HelloRetryRequest, and ServerHello "supported_versions" extensions). In order to maximize interoperability with older endpoints, implementations that negotiate the use of TLS 1.0-1.2 SHOULD set the record layer version number to the negotiated version for the ServerHello and all records thereafter.
先前版本的TLS出于各种目的使用了记录层版本号（TLSPlaintext.legacy_record_version和TLSCiphertext.legacy_record_version）。从TLS 1.3开始，此字段已弃用。所有实现都必须忽略TLSPlaintext.legacy_record_version的值。TLSCiphertext.legacy_record_版本的值包含在用于解除保护的附加数据中，但可能会被忽略，或者可能会被验证为与固定常量值匹配。版本协商仅使用握手版本（ClientHello.legacy_版本和ServerHello.legacy_版本，以及ClientHello、HelloRetryRequest和ServerHello“受支持的_版本”扩展）执行。为了最大限度地提高与旧端点的互操作性，协商使用TLS 1.0-1.2的实现应将ServerHello及其后所有记录的记录层版本号设置为协商版本。
For maximum compatibility with previously non-standard behavior and misconfigured deployments, all implementations SHOULD support validation of certification paths based on the expectations in this document, even when handling prior TLS versions' handshakes (see Section 4.4.2.2).
为了最大限度地兼容以前的非标准行为和错误配置的部署，所有实现都应支持基于本文档中预期的认证路径验证，即使在处理以前TLS版本的握手时也是如此（参见第4.4.2.2节）。
TLS 1.2 and prior supported an "Extended Master Secret" [RFC7627] extension which digested large parts of the handshake transcript into the master secret. Because TLS 1.3 always hashes in the transcript up to the server Finished, implementations which support both TLS 1.3 and earlier versions SHOULD indicate the use of the Extended Master Secret extension in their APIs whenever TLS 1.3 is used.
TLS1.2及之前版本支持“扩展主密钥”[RFC7627]扩展，该扩展将握手转录本的大部分内容消化为主密钥。由于TLS 1.3总是在记录中进行哈希运算，直到服务器完成为止，因此支持TLS 1.3和早期版本的实现应该在使用TLS 1.3时在其API中指示使用扩展主密钥扩展。
A TLS 1.3 client who wishes to negotiate with servers that do not support TLS 1.3 will send a normal TLS 1.3 ClientHello containing 0x0303 (TLS 1.2) in ClientHello.legacy_version but with the correct version(s) in the "supported_versions" extension. If the server does not support TLS 1.3, it will respond with a ServerHello containing an older version number. If the client agrees to use this version, the negotiation will proceed as appropriate for the negotiated protocol. A client using a ticket for resumption SHOULD initiate the connection using the version that was previously negotiated.
希望与不支持TLS 1.3的服务器协商的TLS 1.3客户端将发送一个正常的TLS 1.3 ClientHello，其中ClientHello.legacy_版本中包含0x0303（TLS 1.2），但“supported_versions”扩展中包含正确的版本。如果服务器不支持TLS 1.3，它将使用包含旧版本号的ServerHello进行响应。如果客户同意使用此版本，则协商将根据协商协议进行。使用票据进行恢复的客户端应使用先前协商的版本启动连接。
Note that 0-RTT data is not compatible with older servers and SHOULD NOT be sent absent knowledge that the server supports TLS 1.3. See Appendix D.3.
请注意，0-RTT数据与旧服务器不兼容，如果不知道服务器支持TLS 1.3，则不应发送该数据。见附录D.3。
If the version chosen by the server is not supported by the client (or is not acceptable), the client MUST abort the handshake with a "protocol_version" alert.
如果客户端不支持服务器选择的版本（或不可接受），则客户端必须通过“协议版本”警报中止握手。
Some legacy server implementations are known to not implement the TLS specification properly and might abort connections upon encountering TLS extensions or versions which they are not aware of. Interoperability with buggy servers is a complex topic beyond the scope of this document. Multiple connection attempts may be required in order to negotiate a backward-compatible connection; however, this practice is vulnerable to downgrade attacks and is NOT RECOMMENDED.
已知一些旧服务器实现没有正确实现TLS规范，并且在遇到他们不知道的TLS扩展或版本时可能会中止连接。与有缺陷服务器的互操作性是一个复杂的主题，超出了本文档的范围。为了协商向后兼容的连接，可能需要多次连接尝试；但是，这种做法容易受到降级攻击，因此不推荐使用。
A TLS server can also receive a ClientHello indicating a version number smaller than its highest supported version. If the "supported_versions" extension is present, the server MUST negotiate using that extension as described in Section 4.2.1. If the "supported_versions" extension is not present, the server MUST negotiate the minimum of ClientHello.legacy_version and TLS 1.2. For example, if the server supports TLS 1.0, 1.1, and 1.2, and legacy_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If the "supported_versions" extension is absent and the server only supports versions greater than ClientHello.legacy_version, the server MUST abort the handshake with a "protocol_version" alert.
TLS服务器还可以接收一个ClientHello，该ClientHello指示的版本号小于其支持的最高版本。如果存在“受支持的_版本”扩展，服务器必须按照第4.2.1节所述使用该扩展进行协商。如果“受支持的_版本”扩展不存在，服务器必须协商ClientHello.legacy_版本和TLS 1.2的最小值。例如，如果服务器支持TLS 1.0、1.1和1.2，并且旧版本为TLS 1.0，则服务器将继续使用TLS 1.0 ServerHello。如果缺少“受支持的\u版本”扩展，并且服务器仅支持大于ClientHello.legacy\u版本的版本，则服务器必须使用“协议\u版本”警报中止握手。
Note that earlier versions of TLS did not clearly specify the record layer version number value in all cases (TLSPlaintext.legacy_record_version). Servers will receive various TLS 1.x versions in this field, but its value MUST always be ignored.
请注意，早期版本的TLS并没有在所有情况下明确指定记录层版本号值（TLSPlaintext.legacy_record_version）。服务器将在此字段中接收各种TLS 1.x版本，但必须始终忽略其值。
0-RTT data is not compatible with older servers. An older server will respond to the ClientHello with an older ServerHello, but it will not correctly skip the 0-RTT data and will fail to complete the handshake. This can cause issues when a client attempts to use 0-RTT, particularly against multi-server deployments. For example, a deployment could deploy TLS 1.3 gradually with some servers implementing TLS 1.3 and some implementing TLS 1.2, or a TLS 1.3 deployment could be downgraded to TLS 1.2.
0-RTT数据与旧服务器不兼容。旧服务器将使用旧服务器Hello响应ClientHello，但它不会正确跳过0-RTT数据，并且无法完成握手。当客户端尝试使用0-RTT时，这可能会导致问题，特别是在多服务器部署时。例如，部署可以逐步部署TLS 1.3，有些服务器实现TLS 1.3，有些服务器实现TLS 1.2，或者TLS 1.3部署可以降级为TLS 1.2。
A client that attempts to send 0-RTT data MUST fail a connection if it receives a ServerHello with TLS 1.2 or older. It can then retry the connection with 0-RTT disabled. To avoid a downgrade attack, the client SHOULD NOT disable TLS 1.3, only 0-RTT.
尝试发送0-RTT数据的客户端如果接收到TLS 1.2或更高版本的ServerHello，则连接必须失败。然后，它可以在禁用0-RTT的情况下重试连接。为了避免降级攻击，客户端不应禁用TLS 1.3，而应仅禁用0-RTT。
To avoid this error condition, multi-server deployments SHOULD ensure a uniform and stable deployment of TLS 1.3 without 0-RTT prior to enabling 0-RTT.
为了避免这种错误情况，多服务器部署应确保在启用0-RTT之前，在不使用0-RTT的情况下统一、稳定地部署TLS 1.3。
Field measurements [Ben17a] [Ben17b] [Res17a] [Res17b] have found that a significant number of middleboxes misbehave when a TLS client/server pair negotiates TLS 1.3. Implementations can increase the chance of making connections through those middleboxes by making the TLS 1.3 handshake look more like a TLS 1.2 handshake:
现场测量[Ben17a][Ben17b][Res17a][Res17b]发现，当TLS客户机/服务器对协商TLS 1.3时，大量的中间盒出现异常行为。通过使TLS 1.3握手看起来更像TLS 1.2握手，实现可以增加通过这些中间盒建立连接的机会：
- The client always provides a non-empty session ID in the ClientHello, as described in the legacy_session_id section of Section 4.1.2.
- 客户端总是在ClientHello中提供一个非空会话ID，如第4.1.2节的遗留会话ID部分所述。
- If not offering early data, the client sends a dummy change_cipher_spec record (see the third paragraph of Section 5) immediately before its second flight. This may either be before its second ClientHello or before its encrypted handshake flight. If offering early data, the record is placed immediately after the first ClientHello.
- 如果不提供早期数据，客户在第二次飞行前立即发送一份虚拟更改密码规格记录（见第5节第三段）。这可能在第二次ClientHello之前，也可能在加密握手飞行之前。如果提供早期数据，则记录将立即放在第一个ClientHello之后。
- The server sends a dummy change_cipher_spec record immediately after its first handshake message. This may either be after a ServerHello or a HelloRetryRequest.
- 服务器在第一次握手消息后立即发送一个虚拟更改密码规范记录。这可能是在ServerHello或HelloRetryRequest之后。
When put together, these changes make the TLS 1.3 handshake resemble TLS 1.2 session resumption, which improves the chance of successfully connecting through middleboxes. This "compatibility mode" is partially negotiated: the client can opt to provide a session ID or not, and the server has to echo it. Either side can send
综合起来，这些更改使TLS 1.3握手类似于TLS 1.2会话恢复，从而提高了通过中间盒成功连接的机会。这种“兼容性模式”是部分协商的：客户端可以选择是否提供会话ID，服务器必须回显它。任何一方都可以发送
change_cipher_spec at any time during the handshake, as they must be ignored by the peer, but if the client sends a non-empty session ID, the server MUST send the change_cipher_spec as described in this appendix.
在握手过程中随时更改密码规格，因为对等方必须忽略它们，但如果客户端发送非空会话ID，服务器必须按照本附录中的说明发送更改密码规格。
Implementations negotiating the use of older versions of TLS SHOULD prefer forward secret and AEAD cipher suites, when available.
协商使用较旧版本TLS的实现应首选forward secret和AEAD密码套件（如果可用）。
The security of RC4 cipher suites is considered insufficient for the reasons cited in [RFC7465]. Implementations MUST NOT offer or negotiate RC4 cipher suites for any version of TLS for any reason.
由于[RFC7465]中引用的原因，认为RC4密码套件的安全性不足。实施不得出于任何原因为任何版本的TLS提供或协商RC4密码套件。
Old versions of TLS permitted the use of very low strength ciphers. Ciphers with a strength less than 112 bits MUST NOT be offered or negotiated for any version of TLS for any reason.
TLS的旧版本允许使用非常低强度的密码。不得出于任何原因为任何版本的TLS提供或协商强度小于112位的密码。
The security of SSL 3.0 [RFC6101] is considered insufficient for the reasons enumerated in [RFC7568], and it MUST NOT be negotiated for any reason.
由于[RFC7568]中列举的原因，SSL 3.0[RFC6101]的安全性被认为是不充分的，因此不得以任何理由对其进行协商。
The security of SSL 2.0 [SSL2] is considered insufficient for the reasons enumerated in [RFC6176], and it MUST NOT be negotiated for any reason.
由于[RFC6176]中列举的原因，SSL 2.0[SSL2]的安全性被认为是不充分的，因此不得以任何理由对其进行协商。
Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-HELLO. Implementations MUST NOT negotiate TLS 1.3 or later using an SSL version 2.0 compatible CLIENT-HELLO. Implementations are NOT RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in order to negotiate older versions of TLS.
实施不得发送SSL版本2.0兼容的CLIENT-HELLO。实施不得使用SSL版本2.0兼容的CLIENT-HELLO协商TLS 1.3或更高版本。为了协商较旧版本的TLS，建议实现不接受SSL版本2.0兼容的CLIENT-HELLO。
Implementations MUST NOT send a ClientHello.legacy_version or ServerHello.legacy_version set to 0x0300 or less. Any endpoint receiving a Hello message with ClientHello.legacy_version or ServerHello.legacy_version set to 0x0300 MUST abort the handshake with a "protocol_version" alert.
实现不得将ClientHello.legacy_版本或ServerHello.legacy_版本设置为0x0300或更低。任何接收ClientHello.legacy_版本或ServerHello.legacy_版本设置为0x0300的Hello消息的端点都必须使用“协议_版本”警报中止握手。
Implementations MUST NOT send any records with a version less than 0x0300. Implementations SHOULD NOT accept any records with a version less than 0x0300 (but may inadvertently do so if the record version number is ignored completely).
实现不得发送任何版本低于0x0300的记录。实现不应接受版本低于0x0300的任何记录（但如果完全忽略记录版本号，则可能会无意中接受）。
Implementations MUST NOT use the Truncated HMAC extension, defined in Section 7 of [RFC6066], as it is not applicable to AEAD algorithms and has been shown to be insecure in some scenarios.
实现不得使用[RFC6066]第7节中定义的截断HMAC扩展，因为它不适用于AEAD算法，并且在某些场景中已被证明是不安全的。
A complete security analysis of TLS is outside the scope of this document. In this appendix, we provide an informal description of the desired properties as well as references to more detailed work in the research literature which provides more formal definitions.
TLS的完整安全性分析不在本文件范围内。在本附录中，我们提供了所需属性的非正式描述，以及研究文献中更详细工作的参考资料，这些研究文献提供了更正式的定义。
We cover properties of the handshake separately from those of the record layer.
我们将分别讨论握手的属性和记录层的属性。
The TLS handshake is an Authenticated Key Exchange (AKE) protocol which is intended to provide both one-way authenticated (server-only) and mutually authenticated (client and server) functionality. At the completion of the handshake, each side outputs its view of the following values:
TLS握手是一种经过身份验证的密钥交换（AKE）协议，旨在提供单向身份验证（仅限服务器）和相互身份验证（客户端和服务器）功能。握手完成后，每一方输出其对以下值的看法：
- A set of "session keys" (the various secrets derived from the master secret) from which can be derived a set of working keys.
- 一组“会话密钥”（从主密钥派生的各种密钥），从中可以派生出一组工作密钥。
- A set of cryptographic parameters (algorithms, etc.).
- 一组加密参数（算法等）。
- The identities of the communicating parties.
- 通信方的身份。
We assume the attacker to be an active network attacker, which means it has complete control over the network used to communicate between the parties [RFC3552]. Even under these conditions, the handshake should provide the properties listed below. Note that these properties are not necessarily independent, but reflect the protocol consumers' needs.
我们假设攻击者是主动网络攻击者，这意味着它完全控制用于各方之间通信的网络[RFC3552]。即使在这些条件下，握手也应提供下列属性。请注意，这些属性不一定是独立的，但反映了协议使用者的需求。
Establishing the same session keys: The handshake needs to output the same set of session keys on both sides of the handshake, provided that it completes successfully on each endpoint (see [CK01], Definition 1, part 1).
建立相同的会话密钥：握手需要在握手的两侧输出相同的会话密钥集，前提是它在每个端点上成功完成（参见[CK01]，定义1，第1部分）。
Secrecy of the session keys: The shared session keys should be known only to the communicating parties and not to the attacker (see [CK01], Definition 1, part 2). Note that in a unilaterally authenticated connection, the attacker can establish its own session keys with the server, but those session keys are distinct from those established by the client.
会话密钥的保密性：共享会话密钥应仅为通信方而非攻击者所知（见[CK01]，定义1，第2部分）。请注意，在单向身份验证的连接中，攻击者可以与服务器建立自己的会话密钥，但这些会话密钥与客户端建立的会话密钥不同。
Peer authentication: The client's view of the peer identity should reflect the server's identity. If the client is authenticated, the server's view of the peer identity should match the client's identity.
对等身份验证：客户端对对等身份的视图应该反映服务器的身份。如果客户端经过身份验证，则服务器的对等身份视图应与客户端的身份匹配。
Uniqueness of the session keys: Any two distinct handshakes should produce distinct, unrelated session keys. Individual session keys produced by a handshake should also be distinct and independent.
会话密钥的唯一性：任何两个不同的握手都应该产生不同的、不相关的会话密钥。握手产生的单个会话密钥也应该是不同的和独立的。
Downgrade protection: The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack (see [BBFGKZ16], Definitions 8 and 9).
降级保护：双方的加密参数应该相同，并且应该与对等方在没有攻击的情况下进行通信时相同（参见[BBFGKZ16]，定义8和9）。
Forward secret with respect to long-term keys: If the long-term keying material (in this case the signature keys in certificate-based authentication modes or the external/resumption PSK in PSK with (EC)DHE modes) is compromised after the handshake is complete, this does not compromise the security of the session key (see [DOW92]), as long as the session key itself has been erased. The forward secrecy property is not satisfied when PSK is used in the "psk_ke" PskKeyExchangeMode.
关于长期密钥的转发秘密：如果在握手完成后，长期密钥材料（在这种情况下，基于证书的身份验证模式下的签名密钥或带有（EC）DHE模式的PSK中的外部/恢复PSK）被泄露，这不会泄露会话密钥的安全性（参见[DOW92]），只要会话密钥本身已被擦除。在“PSK_ke”PskKeyExchangeMode中使用PSK时，不满足前向保密属性。
Key Compromise Impersonation (KCI) resistance: In a mutually authenticated connection with certificates, compromising the long-term secret of one actor should not break that actor's authentication of their peer in the given connection (see [HGFS15]). For example, if a client's signature key is compromised, it should not be possible to impersonate arbitrary servers to that client in subsequent handshakes.
密钥泄露模拟（KCI）抵抗：在具有证书的相互认证连接中，泄露一个参与者的长期秘密不应破坏该参与者在给定连接中对其对等方的认证（参见[HGFS15]）。例如，如果客户机的签名密钥被泄露，则在随后的握手中不可能向该客户机模拟任意服务器。
Protection of endpoint identities: The server's identity (certificate) should be protected against passive attackers. The client's identity should be protected against both passive and active attackers.
端点身份保护：应保护服务器的身份（证书）免受被动攻击者的攻击。应保护客户端的身份免受被动和主动攻击者的攻击。
Informally, the signature-based modes of TLS 1.3 provide for the establishment of a unique, secret, shared key established by an (EC)DHE key exchange and authenticated by the server's signature over the handshake transcript, as well as tied to the server's identity by a MAC. If the client is authenticated by a certificate, it also signs over the handshake transcript and provides a MAC tied to both identities. [SIGMA] describes the design and analysis of this type of key exchange protocol. If fresh (EC)DHE keys are used for each connection, then the output keys are forward secret.
非正式地说，TLS 1.3基于签名的模式提供了由（EC）DHE密钥交换建立的唯一、秘密、共享密钥的建立，并通过握手记录本上的服务器签名进行认证，以及通过MAC绑定到服务器的身份。如果客户端通过证书进行身份验证，它也会在握手记录上签名，并提供一个与两个身份绑定的MAC。[SIGMA]描述了此类密钥交换协议的设计和分析。如果每个连接都使用新（EC）DHE密钥，则输出密钥是前向密钥。
The external PSK and resumption PSK bootstrap from a long-term shared secret into a unique per-connection set of short-term session keys. This secret may have been established in a previous handshake. If PSK with (EC)DHE key establishment is used, these session keys will also be forward secret. The resumption PSK has been designed so that the resumption master secret computed by connection N and needed to form connection N+1 is separate from the traffic keys used by
外部PSK和恢复PSK引导从长期共享密钥转换为每个连接的唯一短期会话密钥集。这个秘密可能是在以前的握手中确定的。如果使用带有（EC）DHE密钥建立的PSK，这些会话密钥也将是前向密钥。恢复PSK的设计使得由连接N计算并形成连接N+1所需的恢复主密钥与所使用的业务密钥分离
connection N, thus providing forward secrecy between the connections. In addition, if multiple tickets are established on the same connection, they are associated with different keys, so compromise of the PSK associated with one ticket does not lead to the compromise of connections established with PSKs associated with other tickets. This property is most interesting if tickets are stored in a database (and so can be deleted) rather than if they are self-encrypted.
连接N，从而在连接之间提供前向保密性。此外，如果在同一连接上建立多个票证，则它们与不同的密钥相关联，因此与一个票证相关联的PSK的泄露不会导致与其他票证相关联的PSK建立的连接的泄露。如果票证存储在数据库中（因此可以删除），而不是它们是自加密的，则此属性最有趣。
The PSK binder value forms a binding between a PSK and the current handshake, as well as between the session where the PSK was established and the current session. This binding transitively includes the original handshake transcript, because that transcript is digested into the values which produce the resumption master secret. This requires that both the KDF used to produce the resumption master secret and the MAC used to compute the binder be collision resistant. See Appendix E.1.1 for more on this. Note: The binder does not cover the binder values from other PSKs, though they are included in the Finished MAC.
PSK绑定值在PSK和当前握手之间以及在建立PSK的会话和当前会话之间形成绑定。这种绑定可传递地包括原始握手转录本，因为该转录本被分解为产生主密钥的值。这要求用于生成恢复主密钥的KDF和用于计算绑定的MAC都具有抗冲突性。有关这方面的更多信息，请参见附录E.1.1。注：尽管已完成的MAC中包含了其他PSK的粘合剂值，但粘合剂不包括这些值。
TLS does not currently permit the server to send a certificate_request message in non-certificate-based handshakes (e.g., PSK). If this restriction were to be relaxed in future, the client's signature would not cover the server's certificate directly. However, if the PSK was established through a NewSessionTicket, the client's signature would transitively cover the server's certificate through the PSK binder. [PSK-FINISHED] describes a concrete attack on constructions that do not bind to the server's certificate (see also [Kraw16]). It is unsafe to use certificate-based client authentication when the client might potentially share the same PSK/key-id pair with two different endpoints. Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension.
TLS当前不允许服务器以非基于证书的握手（如PSK）方式发送证书请求消息。如果将来放宽此限制，客户端的签名将不会直接覆盖服务器的证书。但是，如果PSK是通过NewSessionTicket建立的，那么客户端的签名将通过PSK绑定器传递到服务器的证书上。[PSK-FINISHED]描述了对不绑定到服务器证书的构造的具体攻击（另请参见[Kraw16]）。当客户端可能与两个不同的端点共享相同的PSK/密钥id对时，使用基于证书的客户端身份验证是不安全的。除非通过某种扩展协商，否则实现不能将外部PSK与客户端或服务器的基于证书的身份验证相结合。
If an exporter is used, then it produces values which are unique and secret (because they are generated from a unique session key). Exporters computed with different labels and contexts are computationally independent, so it is not feasible to compute one from another or the session secret from the exported value. Note: Exporters can produce arbitrary-length values; if exporters are to be used as channel bindings, the exported value MUST be large enough to provide collision resistance. The exporters provided in TLS 1.3 are derived from the same Handshake Contexts as the early traffic keys and the application traffic keys, respectively, and thus have similar security properties. Note that they do not include the client's certificate; future applications which wish to bind to the client's certificate may need to define a new exporter that includes the full handshake transcript.
如果使用导出器，则它会生成唯一且机密的值（因为它们是从唯一会话密钥生成的）。使用不同标签和上下文计算的导出器在计算上是独立的，因此不可能从一个导出器计算另一个导出器，也不可能从导出值计算会话机密。注：导出器可以生成任意长度值；如果导出器要用作通道绑定，则导出的值必须足够大，以提供抗冲突能力。TLS 1.3中提供的导出器分别来自与早期通信密钥和应用程序通信密钥相同的握手上下文，因此具有类似的安全属性。请注意，它们不包括客户的证书；未来希望绑定到客户证书的应用程序可能需要定义一个新的导出程序，其中包含完整的握手成绩单。
For all handshake modes, the Finished MAC (and, where present, the signature) prevents downgrade attacks. In addition, the use of certain bytes in the random nonces as described in Section 4.1.3 allows the detection of downgrade to previous TLS versions. See [BBFGKZ16] for more details on TLS 1.3 and downgrade.
对于所有握手模式，完成的MAC（如果存在，还有签名）可防止降级攻击。此外，如第4.1.3节所述，在随机nonce中使用某些字节允许检测降级到以前的TLS版本。有关TLS 1.3和降级的更多详细信息，请参见[BBFGKZ16]。
As soon as the client and the server have exchanged enough information to establish shared keys, the remainder of the handshake is encrypted, thus providing protection against passive attackers, even if the computed shared key is not authenticated. Because the server authenticates before the client, the client can ensure that if it authenticates to the server, it only reveals its identity to an authenticated server. Note that implementations must use the provided record-padding mechanism during the handshake to avoid leaking information about the identities due to length. The client's proposed PSK identities are not encrypted, nor is the one that the server selects.
一旦客户机和服务器交换了足够的信息以建立共享密钥，握手的其余部分就会被加密，从而提供针对被动攻击者的保护，即使计算出的共享密钥没有经过身份验证。由于服务器在客户端之前进行身份验证，因此客户端可以确保如果向服务器进行身份验证，则只向经过身份验证的服务器显示其身份。注意，在握手过程中，实现必须使用提供的记录填充机制，以避免由于长度而泄漏有关身份的信息。客户端建议的PSK身份未加密，服务器也未选择该身份。
Key derivation in TLS 1.3 uses HKDF as defined in [RFC5869] and its two components, HKDF-Extract and HKDF-Expand. The full rationale for the HKDF construction can be found in [Kraw10] and the rationale for the way it is used in TLS 1.3 in [KW16]. Throughout this document, each application of HKDF-Extract is followed by one or more invocations of HKDF-Expand. This ordering should always be followed (including in future revisions of this document); in particular, one SHOULD NOT use an output of HKDF-Extract as an input to another application of HKDF-Extract without an HKDF-Expand in between. Multiple applications of HKDF-Expand to some of the same inputs are allowed as long as these are differentiated via the key and/or the labels.
TLS 1.3中的关键推导使用[RFC5869]中定义的HKDF及其两个组件HKDF Extract和HKDFEXTRAND。HKDF建设的全部理由见[Kraw10]，以及[KW16]中TLS 1.3中使用的理由。在本文档中，每次应用HKDF Extract之后都会有一次或多次调用HKDF Expand。应始终遵循此订购（包括本文件的未来版本）；特别是，在没有HKDF扩展的情况下，不应将HKDF Extract的输出用作另一个HKDF Extract应用程序的输入。HKDF的多个应用程序可以扩展到一些相同的输入，只要这些输入通过键和/或标签进行区分。
Note that HKDF-Expand implements a pseudorandom function (PRF) with both inputs and outputs of variable length. In some of the uses of HKDF in this document (e.g., for generating exporters and the resumption_master_secret), it is necessary that the application of HKDF-Expand be collision resistant; namely, it should be infeasible to find two different inputs to HKDF-Expand that output the same value. This requires the underlying hash function to be collision resistant and the output length from HKDF-Expand to be of size at least 256 bits (or as much as needed for the hash function to prevent finding collisions).
请注意，HKDF Expand使用可变长度的输入和输出实现伪随机函数（PRF）。在本文件中HKDF的某些用途中（例如，用于生成出口商和恢复主密钥），HKDF的应用必须具有抗冲突性；也就是说，不可能找到输出相同值的两个不同的HKDF Expand输入。这要求底层哈希函数具有抗冲突性，并且HKDF的输出长度至少扩展到256位（或哈希函数防止查找冲突所需的长度）。
A client that has sent authentication data to a server, either during the handshake or in post-handshake authentication, cannot be sure whether the server afterwards considers the client to be authenticated or not. If the client needs to determine if the server considers the connection to be unilaterally or mutually authenticated, this has to be provisioned by the application layer. See [CHHSV17] for details. In addition, the analysis of post-handshake authentication from [Kraw16] shows that the client identified by the certificate sent in the post-handshake phase possesses the traffic key. This party is therefore the client that participated in the original handshake or one to whom the original client delegated the traffic key (assuming that the traffic key has not been compromised).
在握手期间或握手后身份验证中，已向服务器发送身份验证数据的客户端无法确定服务器随后是否认为该客户端已进行身份验证。如果客户机需要确定服务器是否认为连接是单方面的还是相互验证的，则必须由应用层提供。详见[CHHSV17]。此外，来自[Kraw16]的握手后身份验证分析表明，由握手后阶段发送的证书标识的客户端拥有流量密钥。因此，这一方是参与原始握手的客户机，或者是原始客户机将通信密钥委托给的客户机（假设通信密钥未被泄露）。
The 0-RTT mode of operation generally provides security properties similar to those of 1-RTT data, with the two exceptions that the 0-RTT encryption keys do not provide full forward secrecy and that the server is not able to guarantee uniqueness of the handshake (non-replayability) without keeping potentially undue amounts of state. See Section 8 for mechanisms to limit the exposure to replay.
0-RTT操作模式通常提供与1-RTT数据类似的安全属性，但有两个例外，即0-RTT加密密钥不提供完全的前向保密性，并且服务器无法保证握手的唯一性（不可重放性），而不保留可能不适当的状态量。有关限制重播曝光的机制，请参见第8节。
The exporter_master_secret and early_exporter_master_secret are derived to be independent of the traffic keys and therefore do not represent a threat to the security of traffic encrypted with those keys. However, because these secrets can be used to compute any exporter value, they SHOULD be erased as soon as possible. If the total set of exporter labels is known, then implementations SHOULD pre-compute the inner Derive-Secret stage of the exporter computation for all those labels, then erase the [early_]exporter_master_secret, followed by each inner value as soon as it is known that it will not be needed again.
导出器主密钥和早期导出器主密钥独立于流量密钥，因此不会对使用这些密钥加密的流量的安全构成威胁。然而，因为这些秘密可以用来计算任何导出器的值，所以应该尽快删除它们。如果导出器标签的集合是已知的，那么实现应该为所有这些标签预先计算导出器计算的内部派生秘密阶段，然后删除[early_uu]exporter_master_Secret，然后在知道不再需要它时立即删除每个内部值。
TLS does not provide security for handshakes which take place after the peer's long-term secret (signature key or external PSK) is compromised. It therefore does not provide post-compromise security [CCG16], sometimes also referred to as backward or future secrecy. This is in contrast to KCI resistance, which describes the security guarantees that a party has after its own long-term secret has been compromised.
TLS不为对等方的长期秘密（签名密钥或外部PSK）被泄露后发生的握手提供安全性。因此，它不提供泄露后安全[CCG16]，有时也称为后向或未来保密。这与KCI resistance形成对比，KCI resistance描述了一方在其长期秘密被泄露后所拥有的安全保障。
The reader should refer to the following references for analysis of the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], [FGSW16], [LXZFH16], [FG17], and [BBK17].
读者应参考以下参考文献以分析TLS握手：[DFGS15]、[CHSV16]、[DFGS16]、[KW16]、[FGSW16]、[LXZFH16]、[FG17]和[BBK17]。
The record layer depends on the handshake producing strong traffic secrets which can be used to derive bidirectional encryption keys and nonces. Assuming that is true, and the keys are used for no more data than indicated in Section 5.5, then the record layer should provide the following guarantees:
记录层依赖于产生强流量机密的握手，该机密可用于派生双向加密密钥和nonce。假设这是真的，并且密钥用于的数据不超过第5.5节中的规定，则记录层应提供以下保证：
Confidentiality: An attacker should not be able to determine the plaintext contents of a given record.
机密性：攻击者不应该能够确定给定记录的明文内容。
Integrity: An attacker should not be able to craft a new record which is different from an existing record which will be accepted by the receiver.
完整性：攻击者不应能够创建一个新记录，该记录与接收方将接受的现有记录不同。
Order protection/non-replayability: An attacker should not be able to cause the receiver to accept a record which it has already accepted or cause the receiver to accept record N+1 without having first processed record N.
订单保护/不可重放性：攻击者不应使接收方接受其已接受的记录，或使接收方在没有先处理记录N的情况下接受记录N+1。
Length concealment: Given a record with a given external length, the attacker should not be able to determine the amount of the record that is content versus padding.
长度隐藏：给定一个具有给定外部长度的记录，攻击者应该无法确定该记录的内容和填充量。
Forward secrecy after key change: If the traffic key update mechanism described in Section 4.6.3 has been used and the previous generation key is deleted, an attacker who compromises the endpoint should not be able to decrypt traffic encrypted with the old key.
密钥更改后的前向保密：如果使用了第4.6.3节中描述的流量密钥更新机制，并且删除了上一代密钥，则破坏端点的攻击者应无法解密使用旧密钥加密的流量。
Informally, TLS 1.3 provides these properties by AEAD-protecting the plaintext with a strong key. AEAD encryption [RFC5116] provides confidentiality and integrity for the data. Non-replayability is provided by using a separate nonce for each record, with the nonce being derived from the record sequence number (Section 5.3), with the sequence number being maintained independently at both sides; thus, records which are delivered out of order result in AEAD deprotection failures. In order to prevent mass cryptanalysis when the same plaintext is repeatedly encrypted by different users under the same key (as is commonly the case for HTTP), the nonce is formed by mixing
非正式地说，TLS1.3通过AEAD提供这些属性，并使用强密钥保护明文。AEAD加密[RFC5116]为数据提供机密性和完整性。不可重放性是通过为每个记录使用单独的nonce来提供的，nonce是从记录序列号（第5.3节）派生的，序列号在两侧独立维护；因此，无序交付的记录会导致AEAD解除保护失败。当不同用户在同一密钥下重复加密同一明文时（通常是HTTP的情况），为了防止大规模密码分析，通过混合形成nonce
the sequence number with a secret per-connection initialization vector derived along with the traffic keys. See [BT16] for analysis of this construction.
序列号，带有随流量密钥一起导出的每个连接的秘密初始化向量。有关此结构的分析，请参见[BT16]。
The rekeying technique in TLS 1.3 (see Section 7.2) follows the construction of the serial generator as discussed in [REKEY], which shows that rekeying can allow keys to be used for a larger number of encryptions than without rekeying. This relies on the security of the HKDF-Expand-Label function as a pseudorandom function (PRF). In addition, as long as this function is truly one way, it is not possible to compute traffic keys from prior to a key change (forward secrecy).
TLS 1.3（见第7.2节）中的密钥更新技术遵循[密钥更新]中讨论的串行生成器的构造，这表明密钥更新可以允许密钥用于比不进行密钥更新更大数量的加密。这依赖于HKDF扩展标签函数作为伪随机函数（PRF）的安全性。此外，只要该函数是真正的单向函数，就不可能在密钥更改（前向保密）之前计算流量密钥。
TLS does not provide security for data which is communicated on a connection after a traffic secret of that connection is compromised. That is, TLS does not provide post-compromise security/future secrecy/backward secrecy with respect to the traffic secret. Indeed, an attacker who learns a traffic secret can compute all future traffic secrets on that connection. Systems which want such guarantees need to do a fresh handshake and establish a new connection with an (EC)DHE exchange.
TLS不为在连接的流量机密被泄露后在该连接上通信的数据提供安全性。也就是说，TLS不提供关于流量秘密的泄露后安全性/未来保密性/后向保密性。实际上，一个知道了一个流量秘密的攻击者可以计算出该连接上所有未来的流量秘密。需要这种保证的系统需要进行新的握手，并与（EC）DHE交换建立新的连接。
The reader should refer to the following references for analysis of the TLS record layer: [BMMRT15], [BT16], [BDFKPPRSZZ16], [BBK17], and [PS18].
读者应参考以下参考资料以分析TLS记录层：[BMMRT15]、[BT16]、[BDFKPRSZ16]、[BBK17]和[PS18]。
TLS is susceptible to a variety of traffic analysis attacks based on observing the length and timing of encrypted packets [CLINIC] [HCJC16]. This is particularly easy when there is a small set of possible messages to be distinguished, such as for a video server hosting a fixed corpus of content, but still provides usable information even in more complicated scenarios.
TLS容易受到基于观察加密数据包的长度和时间的各种流量分析攻击[CLINIC][HCJC16]。当有一小部分可能的消息需要区分时，这尤其容易，例如对于承载固定内容语料库的视频服务器，但即使在更复杂的场景中仍然提供可用信息。
TLS does not provide any specific defenses against this form of attack but does include a padding mechanism for use by applications: The plaintext protected by the AEAD function consists of content plus variable-length padding, which allows the application to produce arbitrary-length encrypted records as well as padding-only cover traffic to conceal the difference between periods of transmission and periods of silence. Because the padding is encrypted alongside the actual content, an attacker cannot directly determine the length of the padding but may be able to measure it indirectly by the use of timing channels exposed during record processing (i.e., seeing how long it takes to process a record or trickling in records to see
TLS没有针对这种形式的攻击提供任何特定的防御措施，但包含一种供应用程序使用的填充机制：AEAD函数保护的明文由内容加上可变长度填充组成，它允许应用程序生成任意长度的加密记录，并且填充只覆盖通信量，以隐藏传输周期和静默周期之间的差异。由于填充是与实际内容一起加密的，因此攻击者无法直接确定填充的长度，但可以通过使用记录处理过程中公开的计时通道（即，查看处理记录或插入记录所需的时间）间接测量填充的长度
which ones elicit a response from the server). In general, it is not known how to remove all of these channels because even a constant-time padding removal function will likely feed the content into data-dependent functions. At minimum, a fully constant-time server or client would require close cooperation with the application-layer protocol implementation, including making that higher-level protocol constant time.
哪些会引起服务器的响应）。通常，不知道如何删除所有这些通道，因为即使是固定时间的填充删除函数也可能将内容馈送到依赖数据的函数中。至少，完全固定时间的服务器或客户端需要与应用层协议实现密切合作，包括使更高级别的协议固定时间。
Note: Robust traffic analysis defenses will likely lead to inferior performance due to delays in transmitting packets and increased traffic volume.
注意：由于数据包传输延迟和流量增加，强大的流量分析防御可能会导致性能下降。
In general, TLS does not have specific defenses against side-channel attacks (i.e., those which attack the communications via secondary channels such as timing), leaving those to the implementation of the relevant cryptographic primitives. However, certain features of TLS are designed to make it easier to write side-channel resistant code:
一般来说，TLS没有针对侧信道攻击的特定防御（即，那些通过诸如定时之类的辅助信道攻击通信的攻击），将其留给相关密码原语的实现。但是，TLS的某些功能设计为更容易编写抗侧通道代码：
- Unlike previous versions of TLS which used a composite MAC-then-encrypt structure, TLS 1.3 only uses AEAD algorithms, allowing implementations to use self-contained constant-time implementations of those primitives.
- TLS的早期版本使用复合MAC-then加密结构，与此不同，TLS 1.3仅使用AEAD算法，允许实现使用这些原语的自包含常量时间实现。
- TLS uses a uniform "bad_record_mac" alert for all decryption errors, which is intended to prevent an attacker from gaining piecewise insight into portions of the message. Additional resistance is provided by terminating the connection on such errors; a new connection will have different cryptographic material, preventing attacks against the cryptographic primitives that require multiple trials.
- TLS对所有解密错误使用统一的“bad_record_mac”警报，旨在防止攻击者获得对消息部分的分段洞察。通过在此类错误上终止连接提供附加电阻；新连接将具有不同的加密材料，以防止针对需要多次尝试的加密原语的攻击。
Information leakage through side channels can occur at layers above TLS, in application protocols and the applications that use them. Resistance to side-channel attacks depends on applications and application protocols separately ensuring that confidential information is not inadvertently leaked.
通过侧通道的信息泄漏可能发生在TLS之上的层、应用程序协议和使用它们的应用程序中。对侧通道攻击的抵抗力取决于应用程序和应用程序协议，以确保机密信息不会意外泄漏。
Replayable 0-RTT data presents a number of security threats to TLS-using applications, unless those applications are specifically engineered to be safe under replay (minimally, this means idempotent, but in many cases may also require other stronger conditions, such as constant-time response). Potential attacks include:
可重放的0-RTT数据对使用应用程序的TLS造成了许多安全威胁，除非这些应用程序专门设计为在重放下是安全的（最低限度，这意味着幂等的，但在许多情况下还可能需要其他更强的条件，如恒定时间响应）。潜在攻击包括：
- Duplication of actions which cause side effects (e.g., purchasing an item or transferring money) to be duplicated, thus harming the site or the user.
- 重复导致副作用（如购买物品或转账）重复的操作，从而损害网站或用户。
- Attackers can store and replay 0-RTT messages in order to reorder them with respect to other messages (e.g., moving a delete to after a create).
- 攻击者可以存储和重放0-RTT消息，以便根据其他消息对其重新排序（例如，在创建后将删除移动到）。
- Exploiting cache timing behavior to discover the content of 0-RTT messages by replaying a 0-RTT message to a different cache node and then using a separate connection to measure request latency, to see if the two requests address the same resource.
- 利用缓存计时行为发现0-RTT消息的内容，方法是将0-RTT消息重放到不同的缓存节点，然后使用单独的连接测量请求延迟，以查看两个请求是否寻址相同的资源。
If data can be replayed a large number of times, additional attacks become possible, such as making repeated measurements of the speed of cryptographic operations. In addition, they may be able to overload rate-limiting systems. For a further description of these attacks, see [Mac17].
如果数据可以多次重放，则可能会发生其他攻击，例如重复测量加密操作的速度。此外，它们可能会使限速系统过载。有关这些攻击的进一步说明，请参见[Mac17]。
Ultimately, servers have the responsibility to protect themselves against attacks employing 0-RTT data replication. The mechanisms described in Section 8 are intended to prevent replay at the TLS layer but do not provide complete protection against receiving multiple copies of client data. TLS 1.3 falls back to the 1-RTT handshake when the server does not have any information about the client, e.g., because it is in a different cluster which does not share state or because the ticket has been deleted as described in Section 8.1. If the application-layer protocol retransmits data in this setting, then it is possible for an attacker to induce message duplication by sending the ClientHello to both the original cluster (which processes the data immediately) and another cluster which will fall back to 1-RTT and process the data upon application-layer replay. The scale of this attack is limited by the client's willingness to retry transactions and therefore only allows a limited amount of duplication, with each copy appearing as a new connection at the server.
最终，服务器有责任保护自己免受使用0-RTT数据复制的攻击。第8节中描述的机制旨在防止在TLS层重播，但不能提供完整的保护，防止接收多个客户端数据副本。当服务器没有关于客户端的任何信息时，TLS 1.3退回到1-RTT握手，例如，因为它位于不共享状态的不同集群中，或者因为票证已被删除，如第8.1节所述。如果应用层协议在此设置下重新传输数据，则攻击者有可能通过将ClientHello发送到原始群集（立即处理数据）和另一个群集（返回到1-RTT并在应用层重播时处理数据）来诱导消息复制。此攻击的规模受到客户端重试事务意愿的限制，因此只允许有限数量的复制，每个副本在服务器上显示为新连接。
If implemented correctly, the mechanisms described in Sections 8.1 and 8.2 prevent a replayed ClientHello and its associated 0-RTT data from being accepted multiple times by any cluster with consistent state; for servers which limit the use of 0-RTT to one cluster for a single ticket, then a given ClientHello and its associated 0-RTT data will only be accepted once. However, if state is not completely consistent, then an attacker might be able to have multiple copies of the data be accepted during the replication window. Because clients do not know the exact details of server behavior, they MUST NOT send messages in early data which are not safe to have replayed and which they would not be willing to retry across multiple 1-RTT connections.
如果正确实施，第8.1节和第8.2节中描述的机制可防止任何状态一致的集群多次接受重播的ClientHello及其相关的0-RTT数据；对于将0-RTT的使用限制为单个票证的一个集群的服务器，则只接受一次给定的ClientHello及其关联的0-RTT数据。但是，如果状态不完全一致，则攻击者可能会在复制窗口期间接受数据的多个副本。因为客户机不知道服务器行为的确切细节，所以他们不能在早期数据中发送消息，因为这些消息不安全，无法重播，而且他们不愿意在多个1-RTT连接中重试。
Application protocols MUST NOT use 0-RTT data without a profile that defines its use. That profile needs to identify which messages or interactions are safe to use with 0-RTT and how to handle the situation when the server rejects 0-RTT and falls back to 1-RTT.
应用程序协议在没有定义其使用的配置文件的情况下不得使用0-RTT数据。该概要文件需要确定哪些消息或交互可以安全地与0-RTT一起使用，以及当服务器拒绝0-RTT并退回到1-RTT时如何处理这种情况。
In addition, to avoid accidental misuse, TLS implementations MUST NOT enable 0-RTT (either sending or accepting) unless specifically requested by the application and MUST NOT automatically resend 0-RTT data if it is rejected by the server unless instructed by the application. Server-side applications may wish to implement special processing for 0-RTT data for some kinds of application traffic (e.g., abort the connection, request that data be resent at the application layer, or delay processing until the handshake completes). In order to allow applications to implement this kind of processing, TLS implementations MUST provide a way for the application to determine if the handshake has completed.
此外，为避免意外误用，除非应用程序明确要求，否则TLS实现不得启用0-RTT（发送或接受），并且在服务器拒绝0-RTT数据时，除非应用程序指示，否则不得自动重新发送0-RTT数据。服务器端应用程序可能希望对某些类型的应用程序通信量的0-RTT数据执行特殊处理（例如，中止连接、请求在应用程序层重新发送数据，或延迟处理直到握手完成）。为了允许应用程序实现这种处理，TLS实现必须为应用程序提供一种方法来确定握手是否已完成。
Replays of the ClientHello produce the same early exporter, thus requiring additional care by applications which use these exporters. In particular, if these exporters are used as an authentication channel binding (e.g., by signing the output of the exporter), an attacker who compromises the PSK can transplant authenticators between connections without compromising the authentication key.
ClientHello的重放会产生相同的早期导出器，因此使用这些导出器的应用程序需要额外小心。特别是，如果这些导出器用作身份验证通道绑定（例如，通过对导出器的输出进行签名），则破坏PSK的攻击者可以在连接之间移植身份验证器，而不会破坏身份验证密钥。
In addition, the early exporter SHOULD NOT be used to generate server-to-client encryption keys because that would entail the reuse of those keys. This parallels the use of the early application traffic keys only in the client-to-server direction.
此外，早期导出器不应用于生成服务器到客户端的加密密钥，因为这将需要重用这些密钥。这与早期应用程序通信密钥仅在客户端到服务器方向上的使用类似。
Because implementations respond to an invalid PSK binder by aborting the handshake, it may be possible for an attacker to verify whether a given PSK identity is valid. Specifically, if a server accepts both external-PSK handshakes and certificate-based handshakes, a valid PSK identity will result in a failed handshake, whereas an invalid identity will just be skipped and result in a successful certificate handshake. Servers which solely support PSK handshakes may be able to resist this form of attack by treating the cases where there is no valid PSK identity and where there is an identity but it has an invalid binder identically.
由于实现通过中止握手来响应无效的PSK绑定，攻击者可能会验证给定的PSK标识是否有效。具体来说，如果服务器同时接受外部PSK握手和基于证书的握手，有效的PSK标识将导致握手失败，而无效标识将被跳过并导致成功的证书握手。仅支持PSK握手的服务器可以通过处理不存在有效PSK标识和存在标识但具有无效绑定的情况来抵御这种形式的攻击。
TLS 1.3 takes a conservative approach to PSKs by binding them to a specific KDF. By contrast, TLS 1.2 allows PSKs to be used with any hash function and the TLS 1.2 PRF. Thus, any PSK which is used with both TLS 1.2 and TLS 1.3 must be used with only one hash in TLS 1.3, which is less than optimal if users want to provision a single PSK. The constructions in TLS 1.2 and TLS 1.3 are different, although they are both based on HMAC. While there is no known way in which the same PSK might produce related output in both versions, only limited analysis has been done. Implementations can ensure safety from cross-protocol related output by not reusing PSKs between TLS 1.3 and TLS 1.2.
TLS1.3通过将PSK绑定到特定KDF，对PSK采取保守的方法。相比之下，TLS1.2允许PSK与任何哈希函数和TLS1.2 PRF一起使用。因此，与TLS 1.2和TLS 1.3一起使用的任何PSK必须仅与TLS 1.3中的一个哈希一起使用，如果用户想要提供单个PSK，这将不是最优的。TLS 1.2和TLS 1.3中的结构不同，尽管它们都基于HMAC。虽然没有已知的方法可以使同一个PSK在两个版本中都产生相关的输出，但只进行了有限的分析。通过不重用TLS 1.3和TLS 1.2之间的PSK，实现可以确保跨协议相关输出的安全性。
Although TLS 1.3 does not use RSA key transport and so is not directly susceptible to Bleichenbacher-type attacks [Blei98], if TLS 1.3 servers also support static RSA in the context of previous versions of TLS, then it may be possible to impersonate the server for TLS 1.3 connections [JSS15]. TLS 1.3 implementations can prevent this attack by disabling support for static RSA across all versions of TLS. In principle, implementations might also be able to separate certificates with different keyUsage bits for static RSA decryption and RSA signature, but this technique relies on clients refusing to accept signatures using keys in certificates that do not have the digitalSignature bit set, and many clients do not enforce this restriction.
虽然TLS 1.3不使用RSA密钥传输，因此不会直接受到Bleichenbacher类型的攻击[Blei98]，但如果TLS 1.3服务器在以前版本的TLS上下文中也支持静态RSA，则可能会模拟服务器进行TLS 1.3连接[JSS15]。TLS 1.3实现可以通过在所有TLS版本中禁用对静态RSA的支持来防止这种攻击。原则上，实现可能还能够为静态RSA解密和RSA签名分离具有不同密钥使用位的证书，但此技术依赖于客户端拒绝接受使用未设置digitalSignature位的证书中的密钥的签名，并且许多客户端不强制执行此限制。
Contributors
贡献者
Martin Abadi University of California, Santa Cruz abadi@cs.ucsc.edu
马丁阿巴迪加利福尼亚大学，圣克鲁斯abadi@cs.ucsc.edu
Christopher Allen (co-editor of TLS 1.0) Alacrity Ventures ChristopherA@AlacrityManagement.com
克里斯托弗·艾伦（TLS1.0联合编辑）Alacrity VenturesChristopherA@AlacrityManagement.com
Richard Barnes Cisco rlb@ipv.sx
理查德·巴恩斯·思科rlb@ipv.sx
Steven M. Bellovin Columbia University smb@cs.columbia.edu
史蒂文·M·贝洛文哥伦比亚大学smb@cs.columbia.edu
David Benjamin Google davidben@google.com
大卫本杰明谷歌davidben@google.com
Benjamin Beurdouche INRIA & Microsoft Research benjamin.beurdouche@ens.fr
Benjamin Beurdouche INRIA和微软研究部Benjamin。beurdouche@ens.fr
Karthikeyan Bhargavan (editor of [RFC7627]) INRIA karthikeyan.bhargavan@inria.fr
Karthikeyan Bhargavan（编辑[RFC7627]）INRIA Karthikeyan。bhargavan@inria.fr
Simon Blake-Wilson (co-author of [RFC4492]) BCI sblakewilson@bcisse.com
西蒙·布莱克·威尔逊（RFC4492）BCI的合著者sblakewilson@bcisse.com
Nelson Bolyard (co-author of [RFC4492]) Sun Microsystems, Inc. nelson@bolyard.com
Nelson Bolyard（[RFC4492]的合著者）太阳微系统公司。nelson@bolyard.com
Ran Canetti IBM canetti@watson.ibm.com
Ran Canetti IBMcanetti@watson.ibm.com
Matt Caswell OpenSSL matt@openssl.org
Matt Caswell OpenSSLmatt@openssl.org
Stephen Checkoway University of Illinois at Chicago sfc@uic.edu
史蒂芬伊利诺伊大学芝加哥校区sfc@uic.edu
Pete Chown Skygate Technology Ltd pc@skygate.co.uk
彼得·周天门科技有限公司pc@skygate.co.uk
Katriel Cohn-Gordon University of Oxford me@katriel.co.uk
戈登牛津大学me@katriel.co.uk
Cas Cremers University of Oxford cas.cremers@cs.ox.ac.uk
中国科学院中国科学院院士。cremers@cs.ox.ac.uk
Antoine Delignat-Lavaud (co-author of [RFC7627]) INRIA antdl@microsoft.com
Antoine Delignat-Lavaud（[RFC7627]的合著者）INRIAantdl@microsoft.com
Tim Dierks (co-author of TLS 1.0, co-editor of TLS 1.1 and 1.2) Independent tim@dierks.org
Tim Dierks（TLS 1.0的共同作者，TLS 1.1和1.2的共同编辑）独立tim@dierks.org
Roelof DuToit Symantec Corporation roelof_dutoit@symantec.com
Roelof DuToit赛门铁克公司Roelof_dutoit@symantec.com
Taher Elgamal Securify taher@securify.com
塔赫尔·埃尔加马尔证券公司taher@securify.com
Pasi Eronen Nokia pasi.eronen@nokia.com
诺基亚帕西。eronen@nokia.com
Cedric Fournet Microsoft fournet@microsoft.com
Cedric Fournet微软公司fournet@microsoft.com
Anil Gangolli anil@busybuddha.org
安尼尔·甘戈利anil@busybuddha.org
David M. Garrett dave@nulldereference.com
大卫·M·加勒特dave@nulldereference.com
Illya Gerasymchuk Independent illya@iluxonchik.me
伊利亚·杰拉西姆楚克独立报illya@iluxonchik.me
Alessandro Ghedini Cloudflare Inc. alessandro@cloudflare.com
Alessandro Ghedini Cloudflare公司。alessandro@cloudflare.com
Daniel Kahn Gillmor ACLU dkg@fifthhorseman.net
丹尼尔·卡恩·吉尔莫·阿克鲁dkg@fifthhorseman.net
Matthew Green Johns Hopkins University mgreen@cs.jhu.edu
马修·格林约翰·霍普金斯大学mgreen@cs.jhu.edu
Jens Guballa ETAS jens.guballa@etas.com
詹斯·古巴拉·埃塔斯·詹斯。guballa@etas.com
Felix Guenther TU Darmstadt mail@felixguenther.info
费利克斯·根瑟·图达姆施塔特mail@felixguenther.info
Vipul Gupta (co-author of [RFC4492]) Sun Microsystems Laboratories vipul.gupta@sun.com
Vipul Gupta（[RFC4492]的合著者）太阳微系统实验室Vipul。gupta@sun.com
Chris Hawk (co-author of [RFC4492]) Corriente Networks LLC chris@corriente.net
Chris Hawk（[RFC4492]的合著者）Corriente Networks LLCchris@corriente.net
Kipp Hickman
基普·希克曼
Alfred Hoenes
阿尔弗雷德·霍恩斯
David Hopwood Independent Consultant david.hopwood@blueyonder.co.uk
大卫霍普伍德独立顾问大卫。hopwood@blueyonder.co.uk
Marko Horvat MPI-SWS mhorvat@mpi-sws.org
Marko Horvat MPI-SWSmhorvat@mpi-sws.org
Jonathan Hoyland Royal Holloway, University of London jonathan.hoyland@gmail.com
乔纳森霍兰皇家霍洛威，伦敦大学乔纳森。hoyland@gmail.com
Subodh Iyengar Facebook subodh@fb.com
Subodh Iyengar Facebooksubodh@fb.com
Benjamin Kaduk Akamai Technologies kaduk@mit.edu
Benjamin Kaduk Akamai Technologieskaduk@mit.edu
Hubert Kario Red Hat Inc. hkario@redhat.com
休伯特·卡里奥红帽公司。hkario@redhat.com
Phil Karlton (co-author of SSL 3.0)
菲尔·卡尔顿（SSL 3.0的合著者）
Leon Klingele Independent mail@leonklingele.de
利昂·克林格尔独立报mail@leonklingele.de
Paul Kocher (co-author of SSL 3.0) Cryptography Research paul@cryptography.com
Paul Kocher（SSL 3.0的合著者）密码学研究paul@cryptography.com
Hugo Krawczyk IBM hugokraw@us.ibm.com
雨果·克劳奇克hugokraw@us.ibm.com
Adam Langley (co-author of [RFC7627]) Google agl@google.com
亚当·兰利（谷歌[RFC7627]的合著者）agl@google.com
Olivier Levillain ANSSI olivier.levillain@ssi.gouv.fr
奥利维尔·莱维兰·安西·奥利维尔。levillain@ssi.gouv.fr
Xiaoyin Liu University of North Carolina at Chapel Hill xiaoyin.l@outlook.com
刘小银北卡罗来纳大学教堂山分校小尹。l@outlook.com
Ilari Liusvaara Independent ilariliusvaara@welho.com
Ilari Liusvaara独立报ilariliusvaara@welho.com
Atul Luykx K.U. Leuven atul.luykx@kuleuven.be
阿图尔·卢克·鲁汶·阿图尔。luykx@kuleuven.be
Colm MacCarthaigh Amazon Web Services colm@allcosts.net
Colm MacCarthaigh亚马逊网络服务colm@allcosts.net
Carl Mehner USAA carl.mehner@usaa.com
卡尔·梅纳·尤萨·卡尔。mehner@usaa.com
Jan Mikkelsen Transactionware janm@transactionware.com
Jan Mikkelsen交易软件janm@transactionware.com
Bodo Moeller (co-author of [RFC4492]) Google bodo@acm.org
Bodo Moeller（谷歌[RFC4492]的合著者）bodo@acm.org
Kyle Nekritz Facebook knekritz@fb.com
凯尔·内克里茨knekritz@fb.com
Erik Nygren Akamai Technologies erik+ietf@nygren.org
Erik Nygren Akamai技术Erik+ietf@nygren.org
Magnus Nystrom Microsoft mnystrom@microsoft.com
微软公司mnystrom@microsoft.com
Kazuho Oku DeNA Co., Ltd. kazuhooku@gmail.com
和浩奥库德纳有限公司。kazuhooku@gmail.com
Kenny Paterson Royal Holloway, University of London kenny.paterson@rhul.ac.uk
肯尼帕特森皇家霍洛威，伦敦大学肯尼。paterson@rhul.ac.uk
Christopher Patton University of Florida cjpatton@ufl.edu
克里斯托弗巴顿佛罗里达大学cjpatton@ufl.edu
Alfredo Pironti (co-author of [RFC7627]) INRIA alfredo.pironti@inria.fr
阿尔弗雷多·皮龙蒂（RFC7627的合著者）INRIA Alfredo。pironti@inria.fr
Andrei Popov Microsoft andrei.popov@microsoft.com
安德烈·波波夫。popov@microsoft.com
Marsh Ray (co-author of [RFC7627]) Microsoft maray@microsoft.com
Marsh Ray（微软[RFC7627]的合著者）maray@microsoft.com
Robert Relyea Netscape Communications relyea@netscape.com
罗伯特·雷耶网景通信公司relyea@netscape.com
Kyle Rose Akamai Technologies krose@krose.org
Kyle Rose Akamai Technologieskrose@krose.org
Jim Roskind Amazon jroskind@amazon.com
吉姆·罗斯金德·亚马逊jroskind@amazon.com
Michael Sabin
迈克尔·萨宾
Joe Salowey Tableau Software joe@salowey.net
Joe Salowey Tableau软件joe@salowey.net
Rich Salz Akamai rsalz@akamai.com
Rich Salz Akamairsalz@akamai.com
David Schinazi Apple Inc. dschinazi@apple.com
大卫·斯基恩苹果公司。dschinazi@apple.com
Sam Scott Royal Holloway, University of London me@samjs.co.uk
伦敦大学山姆史葛皇家霍洛威me@samjs.co.uk
Thomas Shrimpton University of Florida teshrim@ufl.edu
托马斯佛罗里达大学teshrim@ufl.edu
Dan Simon Microsoft, Inc. dansimon@microsoft.com
丹·西蒙微软公司。dansimon@microsoft.com
Brian Smith Independent brian@briansmith.org
布莱恩·史密斯独立报brian@briansmith.org
Brian Sniffen Akamai Technologies ietf@bts.evenmere.org
Brian Sniffen Akamai Technologiesietf@bts.evenmere.org
Nick Sullivan Cloudflare Inc. nick@cloudflare.com
尼克·沙利文云闪公司。nick@cloudflare.com
Bjoern Tackmann University of California, San Diego btackmann@eng.ucsd.edu
圣地亚哥加利福尼亚大学btackmann@eng.ucsd.edu
Tim Taubert Mozilla ttaubert@mozilla.com
蒂姆·陶伯特·莫齐拉ttaubert@mozilla.com
Martin Thomson Mozilla mt@mozilla.com
马丁·汤姆森·莫齐拉mt@mozilla.com
Hannes Tschofenig Arm Limited Hannes.Tschofenig@arm.com
Hannes Tschofenig Arm Limited Hannes。Tschofenig@arm.com
Sean Turner sn3rd sean@sn3rd.com
肖恩·特纳sean@sn3rd.com
Steven Valdez Google svaldez@google.com
史蒂文·瓦尔迪兹谷歌svaldez@google.com
Filippo Valsorda Cloudflare Inc. filippo@cloudflare.com
Filippo Valsorda Cloudflare公司。filippo@cloudflare.com
Thyla van der Merwe Royal Holloway, University of London tjvdmerwe@gmail.com
伦敦大学霍洛威tjvdmerwe@gmail.com
Victor Vasiliev Google vasilvv@google.com
维克多·瓦西里耶夫谷歌vasilvv@google.com
Hoeteck Wee Ecole Normale Superieure, Paris hoeteck@alum.mit.edu
巴黎高等师范学院hoeteck@alum.mit.edu
Tom Weinstein
汤姆温斯坦
David Wong NCC Group david.wong@nccgroup.trust
王大卫NCC集团大卫。wong@nccgroup.trust
Christopher A. Wood Apple Inc. cawood@apple.com
克里斯托弗·A·伍德苹果公司。cawood@apple.com
Tim Wright Vodafone timothy.wright@vodafone.com
蒂姆·赖特·沃达丰·蒂莫西。wright@vodafone.com
Peter Wu Independent peter@lekensteyn.nl
吴彼得独立报peter@lekensteyn.nl
Kazu Yamamoto Internet Initiative Japan Inc. kazu@iij.ad.jp
山本和津互联网倡议日本公司。kazu@iij.ad.jp
Author's Address
作者地址
Eric Rescorla Mozilla
Eric Rescorla Mozilla
Email: ekr@rtfm.com
Email: ekr@rtfm.com