Network Working Group T. Dierks
Request for Comments: 5246 Independent
Obsoletes: 3268, 4346, 4366 E. Rescorla
Updates: 4492 RTFM, Inc.
Category: Standards Track August 2008
Network Working Group T. Dierks
Request for Comments: 5246 Independent
Obsoletes: 3268, 4346, 4366 E. Rescorla
Updates: 4492 RTFM, Inc.
Category: Standards Track August 2008
The Transport Layer Security (TLS) Protocol Version 1.2
传输层安全（TLS）协议版本1.2
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
本文件规定了传输层安全（TLS）协议的1.2版。TLS协议提供了互联网上的通信安全。该协议允许客户机/服务器应用程序以防止窃听、篡改或消息伪造的方式进行通信。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
1.2. Major Differences from TLS 1.1 .............................5
2. Goals ...........................................................6
3. Goals of This Document ..........................................7
4. Presentation Language ...........................................7
4.1. Basic Block Size ...........................................7
4.2. Miscellaneous ..............................................8
4.3. Vectors ....................................................8
4.4. Numbers ....................................................9
4.5. Enumerateds ................................................9
4.6. Constructed Types .........................................10
4.6.1. Variants ...........................................10
4.7. Cryptographic Attributes ..................................12
4.8. Constants .................................................14
5. HMAC and the Pseudorandom Function .............................14
6. The TLS Record Protocol ........................................15
6.1. Connection States .........................................16
6.2. Record Layer ..............................................19
6.2.1. Fragmentation ......................................19
1. Introduction ....................................................4
1.1. Requirements Terminology ...................................5
1.2. Major Differences from TLS 1.1 .............................5
2. Goals ...........................................................6
3. Goals of This Document ..........................................7
4. Presentation Language ...........................................7
4.1. Basic Block Size ...........................................7
4.2. Miscellaneous ..............................................8
4.3. Vectors ....................................................8
4.4. Numbers ....................................................9
4.5. Enumerateds ................................................9
4.6. Constructed Types .........................................10
4.6.1. Variants ...........................................10
4.7. Cryptographic Attributes ..................................12
4.8. Constants .................................................14
5. HMAC and the Pseudorandom Function .............................14
6. The TLS Record Protocol ........................................15
6.1. Connection States .........................................16
6.2. Record Layer ..............................................19
6.2.1. Fragmentation ......................................19
6.2.2. Record Compression and Decompression ...............20
6.2.3. Record Payload Protection ..........................21
6.2.3.1. Null or Standard Stream Cipher ............22
6.2.3.2. CBC Block Cipher ..........................22
6.2.3.3. AEAD Ciphers ..............................24
6.3. Key Calculation ...........................................25
7. The TLS Handshaking Protocols ..................................26
7.1. Change Cipher Spec Protocol ...............................27
7.2. Alert Protocol ............................................28
7.2.1. Closure Alerts .....................................29
7.2.2. Error Alerts .......................................30
7.3. Handshake Protocol Overview ...............................33
7.4. Handshake Protocol ........................................37
7.4.1. Hello Messages .....................................38
7.4.1.1. Hello Request .............................38
7.4.1.2. Client Hello ..............................39
7.4.1.3. Server Hello ..............................42
7.4.1.4. Hello Extensions ..........................44
7.4.1.4.1. Signature Algorithms ...........45
7.4.2. Server Certificate .................................47
7.4.3. Server Key Exchange Message ........................50
7.4.4. Certificate Request ................................53
7.4.5. Server Hello Done ..................................55
7.4.6. Client Certificate .................................55
7.4.7. Client Key Exchange Message ........................57
7.4.7.1. RSA-Encrypted Premaster Secret Message ....58
7.4.7.2. Client Diffie-Hellman Public Value ........61
7.4.8. Certificate Verify .................................62
7.4.9. Finished ...........................................63
8. Cryptographic Computations .....................................64
8.1. Computing the Master Secret ...............................64
8.1.1. RSA ................................................65
8.1.2. Diffie-Hellman .....................................65
9. Mandatory Cipher Suites ........................................65
10. Application Data Protocol .....................................65
11. Security Considerations .......................................65
12. IANA Considerations ...........................................65
Appendix A. Protocol Data Structures and Constant Values ..........68
A.1. Record Layer ..............................................68
A.2. Change Cipher Specs Message ...............................69
A.3. Alert Messages ............................................69
A.4. Handshake Protocol ........................................70
A.4.1. Hello Messages .....................................71
A.4.2. Server Authentication and Key Exchange Messages ....72
A.4.3. Client Authentication and Key Exchange Messages ....74
A.4.4. Handshake Finalization Message .....................74
A.5. The Cipher Suite ..........................................75
A.6. The Security Parameters ...................................77
6.2.2. Record Compression and Decompression ...............20
6.2.3. Record Payload Protection ..........................21
6.2.3.1. Null or Standard Stream Cipher ............22
6.2.3.2. CBC Block Cipher ..........................22
6.2.3.3. AEAD Ciphers ..............................24
6.3. Key Calculation ...........................................25
7. The TLS Handshaking Protocols ..................................26
7.1. Change Cipher Spec Protocol ...............................27
7.2. Alert Protocol ............................................28
7.2.1. Closure Alerts .....................................29
7.2.2. Error Alerts .......................................30
7.3. Handshake Protocol Overview ...............................33
7.4. Handshake Protocol ........................................37
7.4.1. Hello Messages .....................................38
7.4.1.1. Hello Request .............................38
7.4.1.2. Client Hello ..............................39
7.4.1.3. Server Hello ..............................42
7.4.1.4. Hello Extensions ..........................44
7.4.1.4.1. Signature Algorithms ...........45
7.4.2. Server Certificate .................................47
7.4.3. Server Key Exchange Message ........................50
7.4.4. Certificate Request ................................53
7.4.5. Server Hello Done ..................................55
7.4.6. Client Certificate .................................55
7.4.7. Client Key Exchange Message ........................57
7.4.7.1. RSA-Encrypted Premaster Secret Message ....58
7.4.7.2. Client Diffie-Hellman Public Value ........61
7.4.8. Certificate Verify .................................62
7.4.9. Finished ...........................................63
8. Cryptographic Computations .....................................64
8.1. Computing the Master Secret ...............................64
8.1.1. RSA ................................................65
8.1.2. Diffie-Hellman .....................................65
9. Mandatory Cipher Suites ........................................65
10. Application Data Protocol .....................................65
11. Security Considerations .......................................65
12. IANA Considerations ...........................................65
Appendix A. Protocol Data Structures and Constant Values ..........68
A.1. Record Layer ..............................................68
A.2. Change Cipher Specs Message ...............................69
A.3. Alert Messages ............................................69
A.4. Handshake Protocol ........................................70
A.4.1. Hello Messages .....................................71
A.4.2. Server Authentication and Key Exchange Messages ....72
A.4.3. Client Authentication and Key Exchange Messages ....74
A.4.4. Handshake Finalization Message .....................74
A.5. The Cipher Suite ..........................................75
A.6. The Security Parameters ...................................77
A.7. Changes to RFC 4492 .......................................78
Appendix B. Glossary ..............................................78
Appendix C. Cipher Suite Definitions ..............................83
Appendix D. Implementation Notes ..................................85
D.1. Random Number Generation and Seeding ......................85
D.2. Certificates and Authentication ...........................85
D.3. Cipher Suites .............................................85
D.4. Implementation Pitfalls ...................................85
Appendix E. Backward Compatibility ................................87
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 ................87
E.2. Compatibility with SSL 2.0 ................................88
E.3. Avoiding Man-in-the-Middle Version Rollback ...............90
Appendix F. Security Analysis .....................................91
F.1. Handshake Protocol ........................................91
F.1.1. Authentication and Key Exchange ....................91
F.1.1.1. Anonymous Key Exchange ....................91
F.1.1.2. RSA Key Exchange and Authentication .......92
F.1.1.3. Diffie-Hellman Key Exchange with
Authentication ............................92
F.1.2. Version Rollback Attacks ...........................93
F.1.3. Detecting Attacks Against the Handshake Protocol ...94
F.1.4. Resuming Sessions ..................................94
F.2. Protecting Application Data ...............................94
F.3. Explicit IVs ..............................................95
F.4. Security of Composite Cipher Modes ........................95
F.5. Denial of Service .........................................96
F.6. Final Notes ...............................................96
Normative References ..............................................97
Informative References ............................................98
Working Group Information ........................................101
Contributors .....................................................101
A.7. Changes to RFC 4492 .......................................78
Appendix B. Glossary ..............................................78
Appendix C. Cipher Suite Definitions ..............................83
Appendix D. Implementation Notes ..................................85
D.1. Random Number Generation and Seeding ......................85
D.2. Certificates and Authentication ...........................85
D.3. Cipher Suites .............................................85
D.4. Implementation Pitfalls ...................................85
Appendix E. Backward Compatibility ................................87
E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 ................87
E.2. Compatibility with SSL 2.0 ................................88
E.3. Avoiding Man-in-the-Middle Version Rollback ...............90
Appendix F. Security Analysis .....................................91
F.1. Handshake Protocol ........................................91
F.1.1. Authentication and Key Exchange ....................91
F.1.1.1. Anonymous Key Exchange ....................91
F.1.1.2. RSA Key Exchange and Authentication .......92
F.1.1.3. Diffie-Hellman Key Exchange with
Authentication ............................92
F.1.2. Version Rollback Attacks ...........................93
F.1.3. Detecting Attacks Against the Handshake Protocol ...94
F.1.4. Resuming Sessions ..................................94
F.2. Protecting Application Data ...............................94
F.3. Explicit IVs ..............................................95
F.4. Security of Composite Cipher Modes ........................95
F.5. Denial of Service .........................................96
F.6. Final Notes ...............................................96
Normative References ..............................................97
Informative References ............................................98
Working Group Information ........................................101
Contributors .....................................................101
The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties:
TLS协议的主要目标是在两个通信应用程序之间提供隐私和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。在最底层，在某些可靠传输协议（如TCP[TCP]）之上的是TLS记录协议。TLS记录协议提供具有两个基本属性的连接安全性：
- The connection is private. Symmetric cryptography is used for data encryption (e.g., AES [AES], RC4 [SCH], etc.). The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol). The Record Protocol can also be used without encryption.
- 连接是私有的。对称加密用于数据加密（例如，AES[AES]、RC4[SCH]等）。此对称加密的密钥为每个连接唯一生成，并且基于另一协议（如TLS握手协议）协商的秘密。记录协议也可以在不加密的情况下使用。
- The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA-1, etc.) are used for MAC computations. The Record Protocol can operate without a MAC, but is generally only used in this mode while another protocol is using the Record Protocol as a transport for negotiating security parameters.
- 连接可靠。消息传输包括使用密钥MAC的消息完整性检查。安全散列函数（如SHA-1等）用于MAC计算。记录协议可以在没有MAC的情况下运行，但通常仅在此模式下使用，而另一个协议将记录协议用作协商安全参数的传输。
The TLS Record Protocol is used for encapsulation of various higher-level protocols. One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection security that has three basic properties:
TLS记录协议用于封装各种高级协议。一个这样的封装协议，TLS握手协议，允许服务器和客户端在应用协议发送或接收其第一字节数据之前相互认证并协商加密算法和加密密钥。TLS握手协议提供具有三个基本属性的连接安全性：
- The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers.
- 对等方的身份可以使用非对称或公钥加密（例如RSA[RSA]、DSA[DSS]等）进行身份验证。此身份验证可以是可选的，但通常至少对一个对等方是必需的。
- The negotiation of a shared secret is secure: the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection.
- 共享秘密的协商是安全的：协商的秘密对于窃听者是不可用的，并且对于任何经过验证的连接，都不能获得秘密，即使攻击者可以将自己置于连接的中间。
- The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the parties to the communication.
- 协商是可靠的：任何攻击者都无法在未被通信各方检测到的情况下修改协商通信。
One advantage of TLS is that it is application protocol independent. Higher-level protocols can layer on top of the TLS protocol transparently. The TLS standard, however, does not specify how protocols add security with TLS; the decisions on 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之上运行的协议的设计者和实现者来判断。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [REQ].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[REQ]中的说明进行解释。
This document is a revision of the TLS 1.1 [TLS1.1] protocol which contains improved flexibility, particularly for negotiation of cryptographic algorithms. The major changes are:
本文件是TLS 1.1[TLS1.1]协议的修订版，其中包含改进的灵活性，特别是用于密码算法协商的灵活性。主要的变化是：
- The MD5/SHA-1 combination in the pseudorandom function (PRF) has been replaced with cipher-suite-specified PRFs. All cipher suites in this document use P_SHA256.
- 伪随机函数（PRF）中的MD5/SHA-1组合已替换为密码套件指定的PRF。本文档中的所有密码套件均使用P_SHA256。
- The MD5/SHA-1 combination in the digitally-signed element has been replaced with a single hash. Signed elements now include a field that explicitly specifies the hash algorithm used.
- 数字签名元素中的MD5/SHA-1组合已替换为单个哈希。签名元素现在包含一个字段，该字段显式指定所使用的哈希算法。
- Substantial cleanup to the client's and server's ability to specify which hash and signature algorithms they will accept. Note that this also relaxes some of the constraints on signature and hash algorithms from previous versions of TLS.
- 对客户端和服务器指定接受哪些散列和签名算法的能力进行了实质性清理。请注意，这也放松了TLS以前版本中对签名和哈希算法的一些限制。
- Addition of support for authenticated encryption with additional data modes.
- 增加了对具有附加数据模式的身份验证加密的支持。
- TLS Extensions definition and AES Cipher Suites were merged in from external [TLSEXT] and [TLSAES].
- TLS扩展定义和AES密码套件由外部[TLSEXT]和[TLSAES]合并而成。
- Tighter checking of EncryptedPreMasterSecret version numbers.
- 更严格地检查EncryptedPreMasterSecret版本号。
- Tightened up a number of requirements.
- 收紧了一些要求。
- Verify_data length now depends on the cipher suite (default is still 12).
- 验证_数据长度现在取决于密码套件（默认值仍然为12）。
- Cleaned up description of Bleichenbacher/Klima attack defenses.
- 清理了Bleichenbacher/Klima攻击防御的描述。
- Alerts MUST now be sent in many cases.
- 在许多情况下，现在必须发送警报。
- After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list.
- 在证书请求之后，如果没有可用的证书，客户端现在必须发送一个空的证书列表。
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite.
- TLS_RSA_和_AES_128_CBC_SHA现在是实现密码套件的必备工具。
- Added HMAC-SHA256 cipher suites.
- 添加了HMAC-SHA256密码套件。
- Removed IDEA and DES cipher suites. They are now deprecated and will be documented in a separate document.
- 删除IDEA和DES密码套件。它们现在已被弃用，并将记录在单独的文档中。
- Support for the SSLv2 backward-compatible hello is now a MAY, not a SHOULD, with sending it a SHOULD NOT. Support will probably become a SHOULD NOT in the future.
- 对SSLv2向后兼容hello的支持现在是可能的，而不是应该的，发送它是不应该的。支持很可能会成为未来不应该出现的问题。
- Added limited "fall-through" to the presentation language to allow multiple case arms to have the same encoding.
- 在表示语言中添加了有限的“fall-through”，以允许多个案例臂具有相同的编码。
- Added an Implementation Pitfalls sections
- 添加了一个实现陷阱部分
- The usual clarifications and editorial work.
- 通常的澄清和编辑工作。
The goals of the TLS protocol, in order of priority, are as follows:
TLS协议的目标按优先顺序如下：
1. Cryptographic security: TLS should be used to establish a secure connection between two parties.
1. 加密安全性：应使用TLS在双方之间建立安全连接。
2. Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters without knowledge of one another's code.
2. 互操作性：独立程序员应该能够利用TLS开发应用程序，这些TLS可以在不知道彼此代码的情况下成功地交换加密参数。
3. Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: preventing the need to create a new protocol (and risking the introduction of possible new weaknesses) and avoiding the need to implement an entire new security library.
3. 可扩展性：TLS寻求提供一个框架，在必要时可以将新的公钥和批量加密方法合并到该框架中。这还将实现两个子目标：防止创建新协议的需要（并冒引入可能的新弱点的风险）和避免实现整个新安全库的需要。
4. Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. Additionally, care has been taken to reduce network activity.
4. 相对效率：加密操作往往是CPU密集型的，尤其是公钥操作。因此，TLS协议包含了可选的会话缓存方案，以减少需要从头开始建立的连接数。此外，还注意减少网络活动。
This document and the TLS protocol itself are based on the SSL 3.0 Protocol Specification as published by Netscape. The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that the various versions of TLS and SSL 3.0 do not interoperate (although each protocol incorporates a mechanism by which an implementation can back down to prior versions). This document is intended primarily for readers who will be implementing the protocol and for those doing cryptographic analysis of it. The specification has been written with this in mind, and it is intended to reflect the needs of those two groups. For that reason, many of the algorithm-dependent data structures and rules are included in the body of the text (as opposed to in an appendix), providing easier access to them.
本文档和TLS协议本身基于Netscape发布的SSL 3.0协议规范。此协议与SSL 3.0之间的差异并不显著，但它们的显著性足以使TLS和SSL 3.0的不同版本无法互操作（尽管每个协议都包含一种机制，通过该机制，实现可以返回到以前的版本）。本文档主要面向将要实施协议的读者以及对其进行密码分析的读者。编写规范时就考虑到了这一点，旨在反映这两个群体的需求。因此，许多依赖于算法的数据结构和规则都包含在正文中（而不是附录中），从而更容易访问它们。
This document is not intended to supply any details of service definition or of interface definition, although it does cover select areas of policy as they are required for the maintenance of solid security.
本文档无意提供服务定义或接口定义的任何详细信息，尽管它确实涵盖了维护可靠安全性所需的策略选择领域。
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 syntax draws from several sources in its structure. Although it resembles the programming language "C" in its syntax and XDR [XDR] in both its syntax and intent, it would be risky to draw too many parallels. The purpose of this presentation language is to document TLS only; it has no general application beyond that particular goal.
本文档处理外部表示中的数据格式。将使用以下非常基本且随意定义的表示语法。该语法从其结构中的多个源中提取。尽管它在语法上与编程语言“C”相似，在语法和意图上与XDR[XDR]相似，但画太多的平行线是有风险的。本演示语言仅用于记录TLS；除了这个特定的目标，它没有普遍的应用。
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 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 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]; /* 3 consecutive 3 byte vectors */
opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* 3 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 4.4). On the other hand, longer can represent up to 800 bytes of data, or 400 uint16 elements, and it may be empty. Its encoding will include a
在下面的示例中，强制是一个必须包含300到400字节类型不透明的向量。它永远不会是空的。实际长度字段消耗两个字节，一个uint16，足以表示值400（参见第4.4节）。另一方面，longer可以表示多达800字节的数据或400个uint16元素，并且它可能是空的。其编码将包括
two-byte actual length field prepended to the vector. The length of an encoded vector must be an even multiple of the length of a single element (for example, a 17-byte vector of uint16 would be illegal).
矢量前面的两字节实际长度字段。编码向量的长度必须是单个元素长度的偶数倍（例如，uint16的17字节向量是非法的）。
opaque mandatory<300..400>;
/* length field is 2 bytes, cannot be empty */
uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */
opaque mandatory<300..400>;
/* length field is 2 bytes, cannot be empty */
uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */
The basic numeric data type is an unsigned byte (uint8). All larger numeric data types are formed from fixed-length series of bytes concatenated as described in Section 4.1 and are also unsigned. The following numeric types are predefined.
基本数字数据类型是无符号字节（uint8）。所有较大的数值数据类型都是由固定长度的字节序列组成的，如第4.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 stored in network byte (big-endian) order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060.
规范中此处和其他地方的所有值都以网络字节（big-endian）顺序存储；十六进制字节01 02 03 04表示的uint32相当于十进制值16909060。
Note that in some cases (e.g., DH parameters) it is necessary to represent integers as opaque vectors. In such cases, they are represented as unsigned integers (i.e., leading zero octets are not required even if the most significant bit is set).
请注意，在某些情况下（例如，DH参数），有必要将整数表示为不透明向量。在这种情况下，它们表示为无符号整数（即，即使设置了最高有效位，也不需要前导零八位字节）。
An additional sparse data type is available called enum. A field of type enum can only assume the values declared in the definition. 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。enum类型的字段只能采用定义中声明的值。每个定义都是不同的类型。只能分配或比较相同类型的枚举。枚举的每个元素都必须分配一个值，如下例所示。由于枚举的元素没有顺序，因此可以按任何顺序为它们分配任何唯一的值。
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
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.
在下面的示例中，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 */
For enumerateds that are never converted to external representation, the numerical information may be omitted.
对于从未转换为外部表示的枚举，可以省略数字信息。
enum { low, medium, high } Amount;
enum { low, medium, high } Amount;
Structure types may be constructed from primitive types for convenience. Each specification declares a new, unique type. The syntax for definition is much like that of C.
为方便起见，可以从基元类型构造结构类型。每个规范都声明了一个新的、唯一的类型。定义的语法与C非常相似。
struct {
T1 f1;
T2 f2;
...
Tn fn;
} [[T]];
struct {
T1 f1;
T2 f2;
...
Tn fn;
} [[T]];
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. Structure definitions may be embedded.
结构中的字段可以使用类型的名称进行限定，其语法非常类似于枚举。例如，T.f2引用上一个声明的第二个字段。可以嵌入结构定义。
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. There must be a case arm for every element of the enumeration declared in the select. Case arms have limited fall-through: if two case arms follow in immediate succession with no fields in between, then they
定义的结构可能具有基于环境中可用的某些知识的变体。选择器必须是定义结构定义的可能变量的枚举类型。select中声明的枚举的每个元素都必须有一个大小写臂。案例武器有有限的失败：如果两个案例武器紧随其后，中间没有字段，那么它们
both contain the same fields. Thus, in the example below, "orange" and "banana" both contain V2. Note that this is a new piece of syntax in TLS 1.2.
两者都包含相同的字段。因此，在下面的示例中，“橙色”和“香蕉”都包含V2。注意，这是TLS1.2中的一个新语法。
The body of the variant structure may be given a label for reference. The mechanism by which the variant is selected at runtime is not prescribed by the presentation language.
变体结构的主体可提供一个标签以供参考。表示语言没有规定在运行时选择变体的机制。
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1;
case e2: Te2;
case e3: case e4: Te3;
....
case en: Ten;
} [[fv]];
} [[Tv]];
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1;
case e2: Te2;
case e3: case e4: Te3;
....
case en: Ten;
} [[fv]];
} [[Tv]];
For example:
例如：
enum { apple, orange, banana } VariantTag;
enum { apple, orange, banana } 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 {
select (VariantTag) { /* value of selector is implicit */
case apple:
V1; /* VariantBody, tag = apple */
case orange:
case banana:
V2; /* VariantBody, tag = orange or banana */
} variant_body; /* optional label on variant */
} VariantRecord;
struct {
select (VariantTag) { /* value of selector is implicit */
case apple:
V1; /* VariantBody, tag = apple */
case orange:
case banana:
V2; /* VariantBody, tag = orange or banana */
} variant_body; /* optional label on variant */
} VariantRecord;
The five cryptographic operations -- digital signing, stream cipher encryption, block cipher encryption, authenticated encryption with additional data (AEAD) encryption, and public key encryption -- are designated digitally-signed, stream-ciphered, block-ciphered, aead-ciphered, and public-key-encrypted, respectively. A field's cryptographic processing is specified by prepending an appropriate key word designation before the field's type specification. Cryptographic keys are implied by the current session state (see Section 6.1).
五种加密操作——数字签名、流密码加密、分组密码加密、附加数据认证加密（AEAD）加密和公钥加密——分别指定为数字签名、流密码、分组密码、AEAD密码和公钥加密。字段的加密处理是通过在字段的类型规范之前添加适当的关键字指定来指定的。加密密钥由当前会话状态暗示（参见第6.1节）。
A digitally-signed element is encoded as a struct DigitallySigned:
数字签名元素被编码为结构数字签名：
struct {
SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>;
} DigitallySigned;
struct {
SignatureAndHashAlgorithm algorithm;
opaque signature<0..2^16-1>;
} DigitallySigned;
The algorithm field specifies the algorithm used (see Section 7.4.1.4.1 for the definition of this field). Note that the introduction of the algorithm field is a change from previous versions. The signature is a digital signature using those algorithms over the contents of the element. The contents themselves do not appear on the wire but are simply calculated. The length of the signature is specified by the signing algorithm and key.
算法字段指定使用的算法（该字段的定义见第7.4.1.4.1节）。请注意，算法字段的引入是对以前版本的更改。签名是在元素内容上使用这些算法的数字签名。内容本身不会出现在导线上，而是经过简单计算。签名的长度由签名算法和密钥指定。
In RSA signing, the opaque vector contains the signature generated using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As discussed in [PKCS1], the DigestInfo MUST be DER-encoded [X680] [X690]. For hash algorithms without parameters (which includes SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL, but implementations MUST accept both without parameters and with NULL parameters. Note that earlier versions of TLS used a different RSA signature scheme that did not include a DigestInfo encoding.
在RSA签名中，不透明向量包含使用[PKCS1]中定义的RSASSA-PKCS1-v1_5签名方案生成的签名。如[PKCS1]中所述，摘要信息必须采用DER编码[X680][X690]。对于没有参数的散列算法（包括SHA-1），DigestInfo.AlgorithmIdentifier.parameters字段必须为空，但实现必须同时接受没有参数和有空参数。请注意，TLS的早期版本使用了不同的RSA签名方案，该方案不包括DigestInfo编码。
In DSA, the 20 bytes of the SHA-1 hash are run directly through the Digital Signing Algorithm with no additional hashing. This produces two values, r and s. The DSA signature is an opaque vector, as above, the contents of which are the DER encoding of:
在DSA中，SHA-1散列的20字节直接通过数字签名算法运行，无需额外的散列。这将产生两个值r和s。DSA签名是一个不透明的向量，如上所述，其内容为DER编码：
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Note: In current terminology, DSA refers to the Digital Signature Algorithm and DSS refers to the NIST standard. In the original SSL and TLS specs, "DSS" was used universally. This document uses "DSA" to refer to the algorithm, "DSS" to refer to the standard, and it uses "DSS" in the code point definitions for historical continuity.
注：在当前术语中，DSA指数字签名算法，DSS指NIST标准。在最初的SSL和TLS规范中，“DSS”被普遍使用。本文档使用“DSA”表示算法，“DSS”表示标准，在代码点定义中使用“DSS”表示历史连续性。
In stream cipher encryption, the plaintext is exclusive-ORed with an identical amount of output generated from a cryptographically secure keyed pseudorandom number generator.
在流密码加密中，明文与加密安全密钥伪随机数生成器生成的相同数量的输出进行异或运算。
In block cipher encryption, every block of plaintext encrypts to a block of ciphertext. All block cipher encryption is done in CBC (Cipher Block Chaining) mode, and all items that are block-ciphered will be an exact multiple of the cipher block length.
在分组密码加密中，每个明文块加密为一个密文块。所有的分组密码加密都是在CBC（cipher block Chaining）模式下完成的，所有被分组加密的项目都是密码块长度的精确倍数。
In AEAD encryption, the plaintext is simultaneously encrypted and integrity protected. The input may be of any length, and aead-ciphered output is generally larger than the input in order to accommodate the integrity check value.
在AEAD加密中，明文同时被加密和完整性保护。输入可以是任意长度，aead加密输出通常大于输入，以适应完整性检查值。
In public key encryption, a public key algorithm is used to encrypt data in such a way that it can be decrypted only with the matching private key. A public-key-encrypted element is encoded as an opaque vector <0..2^16-1>, where the length is specified by the encryption algorithm and key.
在公钥加密中，使用公钥算法对数据进行加密，使其只能用匹配的私钥解密。公钥加密元素被编码为不透明向量<0..2^16-1>，其中长度由加密算法和密钥指定。
RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme defined in [PKCS1].
RSA加密使用[PKCS1]中定义的RSAES-PKCS1-v1_5加密方案完成。
In the following example
在下面的示例中
stream-ciphered struct {
uint8 field1;
uint8 field2;
digitally-signed opaque {
uint8 field3<0..255>;
uint8 field4;
};
} UserType;
stream-ciphered struct {
uint8 field1;
uint8 field2;
digitally-signed opaque {
uint8 field3<0..255>;
uint8 field4;
};
} UserType;
The contents of the inner struct (field3 and field4) are used as input for the signature/hash algorithm, and then the entire structure is encrypted with a stream cipher. The length of this structure, in bytes, would be equal to two bytes for field1 and field2, plus two bytes for the signature and hash algorithm, plus two bytes for the length of the signature, plus the length of the output of the signing
内部结构（field3和field4）的内容用作签名/哈希算法的输入，然后使用流密码对整个结构进行加密。此结构的长度（以字节为单位）等于field1和field2的两个字节，签名和哈希算法的两个字节，签名长度的两个字节，签名输出的长度
algorithm. The length of the signature is known because the algorithm and key used for the signing are known prior to encoding or decoding this structure.
算法。签名的长度是已知的，因为用于签名的算法和密钥在编码或解码该结构之前是已知的。
Typed constants can be defined for purposes of specification by declaring a symbol of the desired type and assigning values to it.
通过声明所需类型的符号并为其赋值，可以为规范定义类型化常量。
Under-specified types (opaque, variable-length vectors, and structures that contain opaque) cannot be assigned values. No fields of a multi-element structure or vector may be elided.
在指定的类型（不透明、可变长度向量和包含不透明的结构）下，无法指定值。不得省略多元素结构或向量的任何字段。
For example:
例如：
struct {
uint8 f1;
uint8 f2;
} Example1;
struct {
uint8 f1;
uint8 f2;
} Example1;
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
The TLS record layer uses a keyed Message Authentication Code (MAC) to protect message integrity. The cipher suites defined in this document use a construction known as HMAC, described in [HMAC], which is based on a hash function. Other cipher suites MAY define their own MAC constructions, if needed.
TLS记录层使用密钥消息身份验证码（MAC）来保护消息完整性。本文档中定义的密码套件使用一种称为HMAC的结构，如[HMAC]中所述，它基于哈希函数。如果需要，其他密码套件可以定义自己的MAC构造。
In addition, a construction is required to do expansion of secrets into blocks of data for the purposes of key generation or validation. This pseudorandom function (PRF) takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length.
此外，为了密钥生成或验证的目的，需要一个构造来将秘密扩展到数据块中。该伪随机函数（PRF）以秘密、种子和识别标签作为输入，并产生任意长度的输出。
In this section, we define one PRF, based on HMAC. This PRF with the SHA-256 hash function is used for all cipher suites defined in this document and in TLS documents published prior to this document when TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a stronger standard hash function.
在本节中，我们基于HMAC定义了一个PRF。当协商TLS 1.2时，此带有SHA-256散列函数的PRF用于本文档中定义的所有密码套件以及在本文档之前发布的TLS文档中。新的密码套件必须明确指定PRF，通常应使用TLS PRF和SHA-256或更强的标准哈希函数。
First, we define a data expansion function, P_hash(secret, data), that uses a single hash function to expand a secret and seed into an arbitrary quantity of output:
首先，我们定义了一个数据扩展函数P_hash（secret，data），它使用一个散列函数来扩展一个秘密并将其种子化为任意数量的输出：
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + ...
P_hash（secret，seed）=HMAC_hash（secret，A（1）+seed）+HMAC_hash（secret，A（2）+seed）+HMAC_hash（secret，A（3）+seed）+。。。
where + indicates concatenation.
其中+表示串联。
A() is defined as:
A（）定义为：
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
P_hash can be iterated as many times as necessary to produce the required quantity of data. For example, if P_SHA256 is being used to create 80 bytes of data, it will have to be iterated three times (through A(3)), creating 96 bytes of output data; the last 16 bytes of the final iteration will then be discarded, leaving 80 bytes of output data.
P_散列可以根据需要多次迭代以生成所需数量的数据。例如，如果P_SHA256用于创建80字节的数据，则必须对其进行三次迭代（通过（3）），从而创建96字节的输出数据；最终迭代的最后16个字节将被丢弃，留下80个字节的输出数据。
TLS's PRF is created by applying P_hash to the secret as:
TLS的PRF是通过将P_散列应用于机密创建的，如下所示：
PRF(secret, label, seed) = P_<hash>(secret, label + seed)
PRF(secret, label, seed) = P_<hash>(secret, label + seed)
The label is an ASCII string. It should be included in the exact form it is given without a length byte or trailing null character. For example, the label "slithy toves" would be processed by hashing the following bytes:
标签是ASCII字符串。它应该包含在给定的确切形式中，没有长度字节或尾随空字符。例如，标签“slithy toves”将通过散列以下字节进行处理：
73 6C 69 74 68 79 20 74 6F 76 65 73
73 6C 69 74 68 79 20 74 6F 76 65 73
The TLS Record Protocol is a layered protocol. At each layer, messages may include fields for length, description, and content. The Record Protocol takes messages to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, reassembled, and then delivered to higher-level clients.
TLS记录协议是一个分层协议。在每一层，消息可能包括长度、描述和内容字段。记录协议接收要传输的消息，将数据分割成可管理的块，选择性地压缩数据，应用MAC，加密并传输结果。接收到的数据被解密、验证、解压缩、重新组装，然后发送到更高级别的客户端。
Four protocols that use the record protocol are described in this document: the handshake protocol, the alert protocol, the change cipher spec protocol, and the application data protocol. In order to allow extension of the TLS protocol, additional record content types can be supported by the record protocol. New record content type values are assigned by IANA in the TLS Content Type Registry as described in Section 12.
本文介绍了使用记录协议的四个协议：握手协议、警报协议、更改密码规范协议和应用程序数据协议。为了允许TLS协议的扩展，记录协议可以支持其他记录内容类型。新记录内容类型值由IANA在TLS内容类型注册表中分配，如第12节所述。
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 send an unexpected_message alert.
除非通过某些扩展协商，否则实现不得发送本文档中未定义的记录类型。如果TLS实现接收到意外的记录类型，则必须发送意外的\u消息警报。
Any protocol designed for use over TLS must be carefully designed to deal with all possible attacks against it. As a practical matter, this means that the protocol designer must be aware of what security properties TLS does and does not provide and cannot safely rely on the latter.
任何设计用于TLS的协议都必须仔细设计，以应对所有可能的攻击。实际上，这意味着协议设计者必须了解TLS提供和不提供的安全属性，并且不能安全地依赖后者。
Note in particular that type and length of a record are not protected by encryption. If this information is itself sensitive, application designers may wish to take steps (padding, cover traffic) to minimize information leakage.
请特别注意，记录的类型和长度不受加密保护。如果这些信息本身是敏感的，那么应用程序设计者可能希望采取措施（填充、覆盖流量）来最大限度地减少信息泄漏。
A TLS connection state is the operating environment of the TLS Record Protocol. It specifies a compression algorithm, an encryption algorithm, and a MAC algorithm. In addition, the parameters for these algorithms are known: the MAC key and the bulk encryption keys for the connection in both the read and the write directions. Logically, there are always four connection states outstanding: the current read and write states, and the pending read and write states. All records are processed under the current read and write states. The security parameters for the pending states can be set by the TLS Handshake Protocol, and the ChangeCipherSpec can selectively make either of the pending states current, in which case the appropriate current state is disposed of and replaced with the pending state; the pending state is then reinitialized to an empty state. It is illegal to make a state that has not been initialized with security parameters a current state. The initial current state always specifies that no encryption, compression, or MAC will be used.
TLS连接状态是TLS记录协议的操作环境。它指定了压缩算法、加密算法和MAC算法。此外，这些算法的参数是已知的：读取和写入方向上连接的MAC密钥和批量加密密钥。从逻辑上讲，始终存在四种未完成的连接状态：当前读写状态和挂起读写状态。所有记录都在当前读写状态下处理。待决状态的安全参数可以通过TLS握手协议来设置，并且ChangeCipherSpec可以选择性地使任一待决状态成为当前状态，在这种情况下，适当的当前状态被处理并替换为待决状态；然后将挂起状态重新初始化为空状态。将未使用安全参数初始化的状态设置为当前状态是非法的。初始当前状态始终指定不使用加密、压缩或MAC。
The security parameters for a TLS Connection read and write state are set by providing the following values:
通过提供以下值来设置TLS连接读写状态的安全参数：
connection end Whether this entity is considered the "client" or the "server" in this connection.
连接结束此实体在此连接中被视为“客户端”还是“服务器”。
PRF algorithm An algorithm used to generate keys from the master secret (see Sections 5 and 6.3).
PRF算法用于从主密钥生成密钥的算法（参见第5节和第6.3节）。
bulk encryption algorithm An algorithm to be used for bulk encryption. This specification includes the key size of this algorithm, whether it is a block, stream, or AEAD cipher, the block size of the cipher (if appropriate), and the lengths of explicit and implicit initialization vectors (or nonces).
批量加密算法用于批量加密的算法。此规范包括此算法的密钥大小，无论是块、流还是AEAD密码，密码的块大小（如果合适），以及显式和隐式初始化向量（或nonce）的长度。
MAC algorithm An algorithm to be used for message authentication. This specification includes the size of the value returned by the MAC algorithm.
MAC算法用于消息身份验证的算法。此规范包括MAC算法返回的值的大小。
compression algorithm An algorithm to be used for data compression. This specification must include all information the algorithm requires to do compression.
压缩算法用于数据压缩的算法。此规范必须包含算法进行压缩所需的所有信息。
master secret A 48-byte secret shared between the two peers in the connection.
主密钥连接中两个对等方共享的48字节密钥。
client random A 32-byte value provided by the client.
client random客户端提供的32字节值。
server random A 32-byte value provided by the server.
server random服务器提供的32字节值。
These parameters are defined in the presentation language as:
这些参数在表示语言中定义为：
enum { server, client } ConnectionEnd;
enum { server, client } ConnectionEnd;
enum { tls_prf_sha256 } PRFAlgorithm;
enum { tls_prf_sha256 } PRFAlgorithm;
enum { null, rc4, 3des, aes }
BulkCipherAlgorithm;
enum { null, rc4, 3des, aes }
BulkCipherAlgorithm;
enum { stream, block, aead } CipherType;
enum { stream, block, aead } CipherType;
enum { null, hmac_md5, hmac_sha1, hmac_sha256,
hmac_sha384, hmac_sha512} MACAlgorithm;
enum { null, hmac_md5, hmac_sha1, hmac_sha256,
hmac_sha384, hmac_sha512} MACAlgorithm;
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
/* The algorithms specified in CompressionMethod, PRFAlgorithm,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
/* The algorithms specified in CompressionMethod, PRFAlgorithm,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
The record layer will use the security parameters to generate the following six items (some of which are not required by all ciphers, and are thus empty):
记录层将使用安全参数生成以下六项（其中一些不是所有密码都需要的，因此为空）：
client write MAC key server write MAC key client write encryption key server write encryption key client write IV server write IV
客户端写入MAC密钥服务器写入MAC密钥客户端写入加密密钥服务器写入加密密钥客户端写入IV服务器写入IV
The client write parameters are used by the server when receiving and processing records and vice versa. The algorithm used for generating these items from the security parameters is described in Section 6.3.
服务器在接收和处理记录时使用客户端写入参数，反之亦然。第6.3节描述了用于从安全参数生成这些项的算法。
Once the security parameters have been set and the keys have been generated, the connection states can be instantiated by making them the current states. These current states MUST be updated for each record processed. Each connection state includes the following elements:
一旦设置了安全参数并生成了密钥，就可以通过将它们设置为当前状态来实例化连接状态。必须为处理的每个记录更新这些当前状态。每个连接状态包括以下元素：
compression state The current state of the compression algorithm.
压缩状态压缩算法的当前状态。
cipher state The current state of the encryption algorithm. This will consist of the scheduled key for that connection. For stream ciphers, this will also contain whatever state information is necessary to allow the stream to continue to encrypt or decrypt data.
密码状态加密算法的当前状态。这将包括该连接的计划密钥。对于流密码，它还将包含允许流继续加密或解密数据所需的任何状态信息。
MAC key The MAC key for this connection, as generated above.
MAC密钥此连接的MAC密钥，如上所述。
sequence number Each connection state contains a sequence number, which is maintained separately for read and write states. The sequence number MUST be set to zero whenever a connection state is made the active state. Sequence numbers are of type uint64 and may not exceed 2^64-1. Sequence numbers do not wrap. If a TLS implementation would need to wrap a sequence number, it must renegotiate instead. A sequence number is incremented after each record: specifically, the first record transmitted under a particular connection state MUST use sequence number 0.
序列号每个连接状态都包含一个序列号，该序列号分别针对读和写状态进行维护。每当连接状态变为活动状态时，序列号必须设置为零。序列号为uint64类型，不得超过2^64-1。序列号不换行。如果TLS实现需要包装一个序列号，则必须重新协商。序列号在每个记录之后递增：具体来说，在特定连接状态下传输的第一个记录必须使用序列号0。
The TLS record layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size.
TLS记录层在任意大小的非空块中接收来自更高层的未解释数据。
The record layer fragments information blocks into TLSPlaintext records carrying data in chunks of 2^14 bytes or less. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).
记录层将信息块分割成TLSPlaintext记录，其中包含2^14字节或更少的数据块。客户端消息边界不保留在记录层中（即，相同ContentType的多个客户端消息可能合并到单个TLSPlaintext记录中，或者单个消息可能在多个记录中分段）。
struct {
uint8 major;
uint8 minor;
} ProtocolVersion;
struct {
uint8 major;
uint8 minor;
} ProtocolVersion;
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
type The higher-level protocol used to process the enclosed fragment.
键入用于处理封闭片段的高级协议。
version The version of the protocol being employed. This document describes TLS Version 1.2, which uses the version { 3, 3 }. The version value 3.3 is historical, deriving from the use of {3, 1} for TLS 1.0. (See Appendix A.1.) Note that a client that supports multiple versions of TLS may not know what version will be employed before it receives the ServerHello. See Appendix E for discussion about what record layer version number should be employed for ClientHello.
版本正在使用的协议的版本。本文档描述了TLS版本1.2，它使用版本{3,3}。版本值3.3是历史值，源于对TLS1.0使用{3，1}。（请参阅附录A.1。）注意，支持多个TLS版本的客户端在收到ServerHello之前可能不知道将使用哪个版本。关于ClientHello应采用何种记录层版本号的讨论，请参见附录E。
length The length (in bytes) of the following TLSPlaintext.fragment. The length MUST NOT exceed 2^14.
length以下TLSPlaintext.fragment的长度（以字节为单位）。长度不得超过2^14。
fragment The application data. This data is transparent and treated as an independent block to be dealt with by the higher-level protocol specified by the type field.
分割应用程序数据。该数据是透明的，并被视为一个独立的块，由类型字段指定的高级协议处理。
Implementations MUST NOT send zero-length fragments of Handshake, Alert, or ChangeCipherSpec content types. Zero-length fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure.
实现不得发送握手、警报或ChangeCipherSpec内容类型的零长度片段。可以发送应用程序数据的零长度片段，因为它们可能用作流量分析对策。
Note: Data of different TLS record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection.
注：不同TLS记录层内容类型的数据可以交错。应用程序数据的传输优先级通常低于其他内容类型。但是，必须按照记录层保护的顺序将记录传送到网络。在连接上第一次握手之后的握手过程中，收件人必须接收和处理交错的应用层通信量。
All records are compressed using the compression algorithm defined in the current session state. There is always an active compression algorithm; however, initially it is defined as CompressionMethod.null. The compression algorithm translates a TLSPlaintext structure into a TLSCompressed structure. Compression functions are initialized with default state information whenever a connection state is made active. [RFC3749] describes compression algorithms for TLS.
使用当前会话状态中定义的压缩算法压缩所有记录。总是有一个主动的压缩算法；但是，最初它被定义为CompressionMethod.null。压缩算法将TLSPlaintText结构转换为TLS压缩结构。每当连接状态处于活动状态时，压缩函数都会使用默认状态信息初始化。[RFC3749]描述了TLS的压缩算法。
Compression must be lossless and may not increase the content length by more than 1024 bytes. If the decompression function encounters a TLSCompressed.fragment that would decompress to a length in excess of 2^14 bytes, it MUST report a fatal decompression failure error.
压缩必须是无损的，并且不能将内容长度增加1024字节以上。如果解压缩函数遇到一个TLSCompressed.fragment，它将解压缩到超过2^14字节的长度，则它必须报告一个致命的解压缩失败错误。
struct {
ContentType type; /* same as TLSPlaintext.type */
ProtocolVersion version;/* same as TLSPlaintext.version */
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct {
ContentType type; /* same as TLSPlaintext.type */
ProtocolVersion version;/* same as TLSPlaintext.version */
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
length The length (in bytes) of the following TLSCompressed.fragment. The length MUST NOT exceed 2^14 + 1024.
length以下TLSCompressed.fragment的长度（以字节为单位）。长度不得超过2^14+1024。
fragment The compressed form of TLSPlaintext.fragment.
片段TLSPlaintext.fragment的压缩形式。
Note: A CompressionMethod.null operation is an identity operation; no fields are altered.
注意：CompressionMethod.null操作是标识操作；没有字段被更改。
Implementation note: Decompression functions are responsible for ensuring that messages cannot cause internal buffer overflows.
实现说明：解压缩功能负责确保消息不会导致内部缓冲区溢出。
The encryption and MAC functions translate a TLSCompressed structure into a TLSCiphertext. The decryption functions reverse the process. The MAC of the record also includes a sequence number so that missing, extra, or repeated messages are detectable.
加密和MAC功能将TLS压缩结构转换为TLSCiphertext。解密函数会反转此过程。记录的MAC还包括序列号，以便可以检测到丢失、额外或重复的消息。
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (SecurityParameters.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
case aead: GenericAEADCipher;
} fragment;
} TLSCiphertext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (SecurityParameters.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
case aead: GenericAEADCipher;
} fragment;
} TLSCiphertext;
type The type field is identical to TLSCompressed.type.
类型类型字段与TLSCompressed.type相同。
version The version field is identical to TLSCompressed.version.
版本版本字段与TLSCompressed.version相同。
length The length (in bytes) of the following TLSCiphertext.fragment. The length MUST NOT exceed 2^14 + 2048.
length以下TLSCiphertext.fragment的长度（以字节为单位）。长度不得超过2^14+2048。
fragment The encrypted form of TLSCompressed.fragment, with the MAC.
使用MAC对TLSCompressed.fragment的加密形式进行分段。
Stream ciphers (including BulkCipherAlgorithm.null; see Appendix A.6) convert TLSCompressed.fragment structures to and from stream TLSCiphertext.fragment structures.
流密码（包括BulkCipherGorithm.null；参见附录A.6）将TLSCompressed.fragment结构转换为流TLSCiphertext.fragment结构，并从流TLSCiphertext.fragment结构中转换。
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher;
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher;
The MAC is generated as:
MAC生成为：
MAC(MAC_write_key, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment);
MAC（MAC_write_key，seq_num+TLSCompressed.type+TLSCompressed.version+TLSCompressed.length+TLSCompressed.fragment）；
where "+" denotes concatenation.
其中“+”表示串联。
seq_num The sequence number for this record.
seq_num此记录的序列号。
MAC The MAC algorithm specified by SecurityParameters.mac_algorithm.
MAC由SecurityParameters.MAC_算法指定的MAC算法。
Note that the MAC is computed before encryption. The stream cipher encrypts the entire block, including the MAC. For stream ciphers that do not use a synchronization vector (such as RC4), the stream cipher state from the end of one record is simply used on the subsequent packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption consists of the identity operation (i.e., the data is not encrypted, and the MAC size is zero, implying that no MAC is used). For both null and stream ciphers, TLSCiphertext.length is TLSCompressed.length plus SecurityParameters.mac_length.
请注意，MAC是在加密之前计算的。流密码加密整个块，包括MAC。对于不使用同步向量（如RC4）的流密码，一条记录末尾的流密码状态仅用于后续数据包。如果密码套件为TLS_NULL_WITH_NULL_NULL，则加密包括标识操作（即，数据未加密，MAC大小为零，表示未使用MAC）。对于空密码和流密码，TLSCiphertext.length是TLSCompressed.length加上SecurityParameters.mac_length。
For block ciphers (such as 3DES or AES), the encryption and MAC functions convert TLSCompressed.fragment structures to and from block TLSCiphertext.fragment structures.
对于块密码（如3DES或AES），加密和MAC函数将TLSChepressed.fragment结构转换为块TLSChipherText.fragment结构，并将其转换为块TLSChipherText.fragment结构。
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
The MAC is generated as described in Section 6.2.3.1.
MAC的生成如第6.2.3.1节所述。
IV The Initialization Vector (IV) SHOULD be chosen at random, and MUST be unpredictable. Note that in versions of TLS prior to 1.1, there was no IV field, and the last ciphertext block of the previous record (the "CBC residue") was used as the IV. This was changed to prevent the attacks described in [CBCATT]. For block ciphers, the IV length is of length SecurityParameters.record_iv_length, which is equal to the SecurityParameters.block_size.
IV初始化向量（IV）应随机选择，并且必须是不可预测的。请注意，在1.1之前的TLS版本中，没有IV字段，先前记录的最后一个密文块（“CBC剩余”）被用作IV。这一更改是为了防止[CBCATT]中描述的攻击。对于分组密码，IV长度为SecurityParameters.record_IV_length，等于SecurityParameters.block_size。
padding Padding that is added to force the length of the plaintext to be an integral multiple of the block cipher's block length. The padding MAY be any length up to 255 bytes, as long as it results in the TLSCiphertext.length being an integral multiple of the block length. Lengths longer than necessary might be desirable to frustrate attacks on a protocol that are based on analysis of the lengths of exchanged messages. Each uint8 in the padding data vector MUST be filled with the padding length value. The receiver MUST check this padding and MUST use the bad_record_mac alert to indicate padding errors.
填充添加的填充，用于强制明文长度为分组密码的块长度的整数倍。填充可以是最大255字节的任何长度，只要它导致TLSCiphertext.length是块长度的整数倍。对于基于交换消息长度分析的协议，可能需要更长的长度来阻止攻击。填充数据向量中的每个uint8必须用填充长度值填充。接收器必须检查此填充，并且必须使用bad_record_mac警报来指示填充错误。
padding_length The padding length MUST be such that the total size of the GenericBlockCipher structure is a multiple of the cipher's block length. Legal values range from zero to 255, inclusive. This length specifies the length of the padding field exclusive of the padding_length field itself.
padding_length填充长度必须确保GenericBlockCipher结构的总大小是密码块长度的倍数。合法值的范围从零到255（包括零和255）。此长度指定填充字段的长度，不包括填充长度字段本身。
The encrypted data length (TLSCiphertext.length) is one more than the sum of SecurityParameters.block_length, TLSCompressed.length, SecurityParameters.mac_length, and padding_length.
加密数据长度（TLSCiphertext.length）比SecurityParameters.block_长度、TLSCompressed.length、SecurityParameters.mac_长度和padding_长度之和大一倍。
Example: If the block length is 8 bytes, the content length (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, then the length before padding is 82 bytes (this does not include the
示例：如果块长度为8字节，内容长度（TLSCompressed.length）为61字节，MAC长度为20字节，则填充前的长度为82字节（这不包括
IV. Thus, the padding length modulo 8 must be equal to 6 in order to make the total length an even multiple of 8 bytes (the block length). The padding length can be 6, 14, 22, and so on, through 254. If the padding length were the minimum necessary, 6, the padding would be 6 bytes, each containing the value 6. Thus, the last 8 octets of the GenericBlockCipher before block encryption would be xx 06 06 06 06 06 06 06, where xx is the last octet of the MAC.
四、 因此，为了使总长度为8字节（块长度）的偶数倍，填充长度模8必须等于6。填充长度可以是6、14、22等等，一直到254。如果填充长度为所需的最小值6，则填充将为6个字节，每个字节包含值6。因此，在分组加密之前，GenericBlockCipher的最后8个八位字节将是xx 06，其中xx是MAC的最后一个八位字节。
Note: With block ciphers in CBC mode (Cipher Block Chaining), it is critical that the entire plaintext of the record be known before any ciphertext is transmitted. Otherwise, it is possible for the attacker to mount the attack described in [CBCATT].
注意：对于CBC模式的分组密码（密码分组链接），在传输任何密文之前，必须知道记录的整个明文。否则，攻击者可能会发起[CBCATT]中描述的攻击。
Implementation note: Canvel et al. [CBCTIME] have demonstrated a timing attack on CBC padding based on the time required to compute the MAC. In order to defend against this attack, implementations MUST ensure that record processing time is essentially the same whether or not the padding is correct. In general, the best way to do this is to compute the MAC even if the padding is incorrect, and only then reject the packet. For instance, if the pad appears to be incorrect, the implementation might assume a zero-length pad and then compute the MAC. This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.
实现说明：Canvel等人[CBCTIME]已经证明了基于计算MAC所需时间对CBC填充的定时攻击。为了抵御这种攻击，实现必须确保无论填充是否正确，记录处理时间基本相同。一般来说，最好的方法是计算MAC，即使填充不正确，然后才拒绝数据包。例如，如果pad看起来不正确，那么实现可能会假设一个零长度的pad，然后计算MAC。这留下了一个小的定时信道，因为MAC性能在某种程度上取决于数据片段的大小，但由于现有MAC的大块大小和定时信号的小尺寸，人们认为它不足以被利用。
For AEAD [AEAD] ciphers (such as [CCM] or [GCM]), the AEAD function converts TLSCompressed.fragment structures to and from AEAD TLSCiphertext.fragment structures.
对于AEAD[AEAD]密码（如[CCM]或[GCM]），AEAD函数将TLSCompressed.fragment结构转换为AEAD TLSCiphertext.fragment结构，并将其转换为AEAD TLSCiphertext.fragment结构。
struct {
opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct {
opaque content[TLSCompressed.length];
};
} GenericAEADCipher;
struct {
opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct {
opaque content[TLSCompressed.length];
};
} GenericAEADCipher;
AEAD ciphers 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 [AEAD]. The key is either the client_write_key or the server_write_key. No MAC key is used.
如[AEAD]第2.1节所述，AEAD密码将单个密钥、nonce、明文和“附加数据”作为输入，以包括在认证检查中。该密钥是客户端写入密钥或服务器写入密钥。没有使用MAC密钥。
Each AEAD cipher suite MUST specify how the nonce supplied to the AEAD operation is constructed, and what is the length of the GenericAEADCipher.nonce_explicit part. In many cases, it is
每个AEAD密码套件必须指定如何构造提供给AEAD操作的nonce，以及GenericAEADCipher.nonce\u显式部分的长度。在许多情况下，这是正确的
appropriate to use the partially implicit nonce technique described in Section 3.2.1 of [AEAD]; with record_iv_length being the length of the explicit part. In this case, the implicit part SHOULD be derived from key_block as client_write_iv and server_write_iv (as described in Section 6.3), and the explicit part is included in GenericAEAEDCipher.nonce_explicit.
适用于使用[AEAD]第3.2.1节所述的部分隐式nonce技术；记录的长度为显式部分的长度。在这种情况下，隐式部分应从密钥块中派生出来，作为客户端写入iv和服务器写入iv（如第6.3节所述），显式部分包含在GenericAEAEDCipher.nonce\u explicit中。
The plaintext is the TLSCompressed.fragment.
明文是TLSCompressed.fragment。
The additional authenticated data, which we denote as additional_data, is defined as follows:
附加认证数据（我们称为附加_数据）定义如下：
additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length;
additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length;
where "+" denotes concatenation.
其中“+”表示串联。
The aead_output consists of the ciphertext output by the AEAD encryption operation. The length will generally be larger than TLSCompressed.length, but by an amount that varies with the AEAD cipher. Since the ciphers might incorporate padding, the amount of overhead could vary with different TLSCompressed.length values. Each AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. Symbolically,
aead_输出由aead加密操作输出的密文组成。长度通常会大于TLSCompressed.length，但其大小会随AEAD密码的不同而变化。由于密码可能包含填充，因此开销量可能随TLSCompressed.length值的不同而不同。每个AEAD密码不得产生大于1024字节的扩展。象征性地
AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, additional_data)
AEADEncrypted=AEAD加密（写入密钥、nonce、明文、附加数据）
In order to decrypt and verify, the cipher takes as input the key, nonce, the "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. That is:
为了解密和验证，密码将密钥、nonce、“附加_数据”和AED加密值作为输入。输出为纯文本或指示解密失败的错误。没有单独的完整性检查。即:
TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, AEADEncrypted, additional_data)
TLSCompressed.fragment=AEAD解密（写入密钥、nonce、AED加密、附加数据）
If the decryption fails, a fatal bad_record_mac alert MUST be generated.
如果解密失败，则必须生成致命的坏记录mac警报。
The Record Protocol requires an algorithm to generate keys required by the current connection state (see Appendix A.6) from the security parameters provided by the handshake protocol.
记录协议需要一种算法，根据握手协议提供的安全参数生成当前连接状态所需的密钥（见附录A.6）。
The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. Each of these is generated from the byte sequence in that order. Unused values are empty. Some AEAD ciphers may additionally require a client write IV and a server write IV (see Section 6.2.3.3).
主密钥被扩展为一系列安全字节，然后被拆分为客户端写入MAC密钥、服务器写入MAC密钥、客户端写入加密密钥和服务器写入加密密钥。其中每一个都是按该顺序从字节序列生成的。未使用的值为空。某些AEAD密码可能还需要客户端写入IV和服务器写入IV（见第6.2.3.3节）。
When keys and MAC keys are generated, the master secret is used as an entropy source.
生成密钥和MAC密钥时，主密钥用作熵源。
To generate the key material, compute
要生成关键材质，请计算
key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);
key\u block=PRF（SecurityParameters.master\u secret，“密钥扩展”，SecurityParameters.server\u random+SecurityParameters.client\u random）；
until enough output has been generated. Then, the key_block is partitioned as follows:
直到产生足够的输出。然后，密钥块被划分如下：
client_write_MAC_key[SecurityParameters.mac_key_length]
server_write_MAC_key[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length]
client_write_MAC_key[SecurityParameters.mac_key_length]
server_write_MAC_key[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length]
client_write_IV[SecurityParameters.fixed_iv_length]
server_write_IV[SecurityParameters.fixed_iv_length]
Currently, the client_write_IV and server_write_IV are only generated for implicit nonce techniques as described in Section 3.2.1 of [AEAD].
目前，客户端写入IV和服务器写入IV仅为[AEAD]第3.2.1节所述的隐式nonce技术生成。
Implementation note: The currently defined cipher suite which requires the most material is AES_256_CBC_SHA256. It requires 2 x 32 byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key material.
实施说明：目前定义的密码套件需要最多的资料是AES_256_CBC_SHA256。它需要2 x 32字节的密钥和2 x 32字节的MAC密钥，总共需要128字节的密钥材料。
TLS has three subprotocols that are used to allow peers to agree upon security parameters for the record layer, to authenticate themselves, to instantiate negotiated security parameters, and to report error conditions to each other.
TLS有三个子目录，用于允许对等方就记录层的安全参数达成一致、进行身份验证、实例化协商的安全参数以及相互报告错误情况。
The Handshake Protocol is responsible for negotiating a session, which consists of the following items:
握手协议负责协商会话，会话包括以下各项：
session identifier An arbitrary byte sequence chosen by the server to identify an active or resumable session state.
会话标识符服务器选择的用于标识活动或可恢复会话状态的任意字节序列。
peer certificate X509v3 [PKIX] certificate of the peer. This element of the state may be null.
对等方证书X509v3[PKIX]对等方的证书。状态的此元素可能为null。
compression method The algorithm used to compress data prior to encryption.
压缩方法加密前用于压缩数据的算法。
cipher spec Specifies the pseudorandom function (PRF) used to generate keying material, the bulk data encryption algorithm (such as null, AES, etc.) and the MAC algorithm (such as HMAC-SHA1). It also defines cryptographic attributes such as the mac_length. (See Appendix A.6 for formal definition.)
密码规范规定了用于生成密钥材料的伪随机函数（PRF）、批量数据加密算法（如null、AES等）和MAC算法（如HMAC-SHA1）。它还定义了加密属性，如mac_长度。（正式定义见附录A.6。）
master secret 48-byte secret shared between the client and server.
主密钥客户端和服务器之间共享的48字节密钥。
is resumable A flag indicating whether the session can be used to initiate new connections.
是可恢复的—指示会话是否可用于启动新连接的标志。
These items are then used to create security parameters for use by the record layer when protecting application data. Many connections can be instantiated using the same session through the resumption feature of the TLS Handshake Protocol.
然后，这些项用于创建安全参数，以供记录层在保护应用程序数据时使用。通过TLS握手协议的恢复功能，可以使用同一会话实例化许多连接。
The change cipher spec protocol exists to signal transitions in ciphering strategies. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) connection state. The message consists of a single byte of value 1.
change cipher spec协议存在于加密策略的信号转换中。该协议由单个消息组成，在当前（而不是挂起）连接状态下对其进行加密和压缩。该消息由值为1的单个字节组成。
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
The ChangeCipherSpec message is sent by both the client and the server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys. Reception of this message causes the receiver to instruct the record layer to immediately copy the read pending state into the read current state. Immediately after sending this message, the sender MUST instruct the record layer to make the write pending state the write active state.
ChangeCipherSpec消息由客户端和服务器发送，以通知接收方后续记录将受到新协商的CipherSpec和密钥的保护。接收到该消息后，接收器指示记录层立即将读取挂起状态复制到读取当前状态。发送此消息后，发送方必须立即指示记录层将写挂起状态设置为写活动状态。
(See Section 6.1.) The ChangeCipherSpec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying Finished message is sent.
（参见第6.1节。）在安全参数达成一致后，但在发送验证完成消息之前，在握手过程中发送ChangeCipherSpec消息。
Note: If a rehandshake occurs while data is flowing on a connection, the communicating parties may continue to send data using the old CipherSpec. However, once the ChangeCipherSpec has been sent, the new CipherSpec MUST be used. The first side to send the ChangeCipherSpec does not know that the other side has finished computing the new keying material (e.g., if it has to perform a time-consuming public key operation). Thus, a small window of time, during which the recipient must buffer the data, MAY exist. In practice, with modern machines this interval is likely to be fairly short.
注意：如果数据在连接上流动时发生重新握手，通信双方可以继续使用旧的CipherSpec发送数据。但是，发送ChangeCipherSpec后，必须使用新的CipherSpec。发送ChangeCipherSpec的第一方不知道另一方已完成新密钥材料的计算（例如，如果必须执行耗时的公钥操作）。因此，可能存在接收者必须缓冲数据的小时间窗。实际上，对于现代机器来说，这段时间间隔可能相当短。
One of the content types supported by the TLS record layer is the alert type. Alert messages convey the severity of the message (warning or fatal) and a description of the alert. Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections. Like other messages, alert messages are encrypted and compressed, as specified by the current connection state.
TLS记录层支持的内容类型之一是警报类型。警报消息传达消息的严重性（警告或致命）和警报说明。具有致命级别的警报消息会导致连接立即终止。在这种情况下，与会话相对应的其他连接可能会继续，但会话标识符必须无效，以防止失败的会话用于建立新连接。与其他消息一样，警报消息按照当前连接状态进行加密和压缩。
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(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),
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(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), user_canceled(90), no_renegotiation(100), unsupported_extension(110), (255) } AlertDescription;
导出限制保留（60）、协议版本（70）、安全性不足（71）、内部错误（80）、用户取消（90）、无重新协商（100）、不支持的扩展（110）、（255）}警报说明；
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. Either party may initiate the exchange of closing messages.
客户端和服务器必须共享连接即将结束的知识，以避免截断攻击。任何一方均可发起交易结束信息的交换。
close_notify This message notifies the recipient that the sender will not send any more messages on this connection. Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice.
close_notify此邮件通知收件人发件人将不再在此连接上发送任何邮件。请注意，从TLS 1.1开始，如果无法正确关闭连接，则不再需要继续会话。这是对TLS 1.0的更改，以符合广泛的实施实践。
Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored.
任何一方均可通过发送关闭通知警报启动关闭。关闭警报后收到的任何数据都将被忽略。
Unless some other fatal alert has been transmitted, each party is required to send a close_notify alert before closing the write side of the connection. The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection.
除非传输了其他致命警报，否则各方必须在关闭连接的写入端之前发送close_notify警报。另一方必须以其自身的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 the responding close_notify alert before indicating to the application layer that the TLS connection has ended. If the application protocol will not transfer any additional data, but will only close the underlying transport connection, then the implementation MAY choose to close the transport without waiting for the responding close_notify. No part
如果使用TLS的应用程序协议规定，在TLS连接关闭后，任何数据都可能通过底层传输传输，则TLS实现必须在向应用程序层指示TLS连接已结束之前接收响应的close_notify警报。如果应用程序协议不会传输任何附加数据，而只会关闭底层传输连接，则实现可以选择关闭传输，而不等待响应的关闭通知。没有部分
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.
应采用本标准的第1部分规定TLS的使用概要文件管理其数据传输的方式，包括连接打开或关闭时的方式。
Note: It is assumed that closing a connection reliably delivers pending data before destroying the transport.
注意：假定在销毁传输之前，关闭连接可以可靠地传递挂起的数据。
Error handling in the TLS Handshake protocol is very simple. When an error is detected, the detecting party sends a message to the other party. Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. Servers and clients MUST forget any session-identifiers, keys, and secrets associated with a failed connection. Thus, any connection terminated with a fatal alert MUST NOT be resumed.
TLS握手协议中的错误处理非常简单。当检测到错误时，检测方向另一方发送消息。在传输或接收到致命警报消息后，双方立即关闭连接。服务器和客户端必须忘记与失败连接相关的任何会话标识符、密钥和机密。因此，任何以致命警报终止的连接都不能恢复。
Whenever an implementation encounters a condition which is defined as a fatal alert, it MUST send the appropriate alert prior to closing the connection. For all errors where an alert level is not explicitly specified, the sending party MAY determine at its discretion whether to treat this as a fatal error or not. If the implementation chooses to send an alert but intends to close the connection immediately afterwards, it MUST send that alert at the fatal alert level.
每当实现遇到定义为致命警报的情况时，它必须在关闭连接之前发送相应的警报。对于未明确指定警报级别的所有错误，发送方可自行决定是否将其视为致命错误。如果实现选择发送警报，但打算随后立即关闭连接，则必须以致命警报级别发送该警报。
If an alert with a level of warning is sent and received, generally the connection can continue normally. If the receiving party decides not to proceed with the connection (e.g., after having received a no_renegotiation alert that it is not willing to accept), it SHOULD send a fatal alert to terminate the connection. Given this, the sending party cannot, in general, know how the receiving party will behave. Therefore, warning alerts are not very useful when the sending party wants to continue the connection, and thus are sometimes omitted. For example, if a peer decides to accept an expired certificate (perhaps after confirming this with the user) and wants to continue the connection, it would not generally send a certificate_expired alert.
如果发送和接收到警告级别的警报，通常连接可以正常继续。如果接收方决定不继续连接（例如，在收到其不愿意接受的拒绝重新协商警报后），则应发送致命警报以终止连接。有鉴于此，发送方通常无法知道接收方的行为。因此，当发送方希望继续连接时，警告警报不是很有用，因此有时会被忽略。例如，如果对等方决定接受过期证书（可能在与用户确认后），并希望继续连接，则通常不会发送证书过期警报。
The following error alerts are defined:
定义了以下错误警报：
unexpected_message An inappropriate message was received. This alert is always fatal and should never be observed in communication between proper implementations.
意外消息收到不适当的消息。此警报始终是致命的，在正确实现之间的通信中不应出现此警报。
bad_record_mac This alert is returned if a record is received with an incorrect MAC. This alert also MUST be returned if an alert is sent because a TLSCiphertext decrypted in an invalid way: either it wasn't an even multiple of the block length, or its padding values, when checked, weren't correct. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).
错误\u记录\u mac如果接收到带有错误mac的记录，将返回此警报。如果发送警报的原因是TLSCiphertext以无效方式解密：它不是块长度的偶数倍，或者其填充值（选中时）不正确，则也必须返回此警报。此消息总是致命的，在正确实现之间的通信中不应观察到（除非消息在网络中损坏）。
decryption_failed_RESERVED This alert was used in some earlier versions of TLS, and may have permitted certain attacks against the CBC mode [CBCATT]. It MUST NOT be sent by compliant implementations.
解密\u失败\u保留此警报在某些早期版本的TLS中使用，可能允许对CBC模式[CBCATT]进行某些攻击。它不能由兼容的实现发送。
record_overflow A TLSCiphertext record was received that had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14+1024 bytes. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).
记录溢出收到长度超过2^14+2048字节的TLSCiphertext记录，或解密为长度超过2^14+1024字节的TLSCompressed记录。此消息总是致命的，在正确实现之间的通信中不应观察到（除非消息在网络中损坏）。
decompression_failure The decompression function received improper input (e.g., data that would expand to excessive length). This message is always fatal and should never be observed in communication between proper implementations.
解压失败解压功能接收到不正确的输入（例如，数据会扩展到过长）。此消息总是致命的，在正确实现之间的通信中不应观察到。
handshake_failure Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available. This is a fatal error.
握手失败接收到握手失败警报消息表明，在提供可用选项的情况下，发送方无法协商一组可接受的安全参数。这是一个致命的错误。
no_certificate_RESERVED This alert was used in SSLv3 but not any version of TLS. It MUST NOT be sent by compliant implementations.
无证书\u保留此警报已在SSLv3中使用，但未在TLS的任何版本中使用。它不能由兼容的实现发送。
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.
证书\u已吊销证书的签名者已吊销证书。
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 out of range or inconsistent with other fields. This message is always fatal.
非法参数握手中的字段超出范围或与其他字段不一致。这个消息总是致命的。
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 couldn't be matched with a known, trusted CA. This message is always fatal.
未知\u ca收到有效的证书链或部分链，但证书未被接受，因为找不到ca证书或无法与已知的受信任ca匹配。此消息始终是致命的。
access_denied A valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation. This message is always fatal.
拒绝访问收到有效证书，但当应用访问控制时，发件人决定不继续协商。这个消息总是致命的。
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 message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network).
解码\错误无法解码消息，因为某些字段超出指定范围或消息长度不正确。此消息总是致命的，在正确实现之间的通信中不应观察到（除非消息在网络中损坏）。
decrypt_error A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message. This message is always fatal.
解密错误握手加密操作失败，包括无法正确验证签名或验证完成的消息。这个消息总是致命的。
export_restriction_RESERVED This alert was used in some earlier versions of TLS. It MUST NOT be sent by compliant implementations.
导出限制保留此警报已在某些早期版本的TLS中使用。它不能由兼容的实现发送。
protocol_version The protocol version the client has attempted to negotiate is recognized but not supported. (For example, old protocol versions might be avoided for security reasons.) This message is always fatal.
协议\版本客户端尝试协商的协议版本已被识别，但不受支持。（例如，出于安全原因，可能会避免使用旧的协议版本。）此消息总是致命的。
insufficient_security Returned instead of handshake_failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client. This message is always fatal.
当协商失败时，返回的\u安全性不足，而不是握手\u失败，特别是因为服务器需要比客户端支持的密码更安全的密码。这个消息总是致命的。
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. This message is always fatal.
内部错误与对等方或协议正确性无关的内部错误（如内存分配失败）导致无法继续。这个消息总是致命的。
user_canceled This handshake is being canceled for some reason unrelated to a protocol failure. If the 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 message is generally a warning.
用户_已取消此握手由于与协议故障无关的原因而被取消。如果用户在握手完成后取消操作，则只需发送关闭通知来关闭连接就更合适了。此警报后应发出关闭通知。此消息通常是一个警告。
no_renegotiation Sent by the client in response to a hello request or by the server in response to a client hello after initial handshaking. Either of these would normally lead to renegotiation; when that is not appropriate, the recipient should respond with this alert. At that point, the original requester can decide whether to proceed with the connection. One case where this would be appropriate is where a server has spawned a process to satisfy a request; the process might receive security parameters (key length, authentication, etc.) at startup, and it might be difficult to communicate changes to these parameters after that point. This message is always a warning.
初始握手后，客户端响应hello请求或服务器响应客户端hello时不发送重新协商。其中任何一项通常都会导致重新谈判；当这不合适时，收件人应回复此警报。此时，原始请求者可以决定是否继续连接。一种适当的情况是，服务器产生了一个进程来满足请求；进程在启动时可能会收到安全参数（密钥长度、身份验证等），并且在该点之后可能很难传达对这些参数的更改。此消息始终是一个警告。
unsupported_extension sent by clients that receive an extended server hello containing an extension that they did not put in the corresponding client hello. This message is always fatal.
接收扩展服务器hello的客户端发送的不受支持的_扩展，该扩展包含一个未放入相应客户端hello中的扩展。这个消息总是致命的。
New Alert values are assigned by IANA as described in Section 12.
新警报值由IANA分配，如第12节所述。
The cryptographic parameters of the session state are produced by the TLS Handshake Protocol, which operates on top of the TLS record layer. When a TLS client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets.
会话状态的加密参数由TLS握手协议生成，该协议在TLS记录层上运行。当TLS客户机和服务器第一次开始通信时，它们就协议版本达成一致，选择加密算法，选择性地相互验证，并使用公钥加密技术生成共享机密。
The TLS Handshake Protocol involves the following steps:
TLS握手协议包括以下步骤：
- Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption.
- 交换hello消息以同意算法、交换随机值并检查会话恢复。
- Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret.
- 交换必要的加密参数，以允许客户端和服务器就主密钥达成一致。
- Exchange certificates and cryptographic information to allow the client and server to authenticate themselves.
- 交换证书和加密信息以允许客户端和服务器进行自身身份验证。
- Generate a master secret from the premaster secret and exchanged random values.
- 从主密钥和交换的随机值生成主密钥。
- Provide security parameters to the record layer.
- 向记录层提供安全参数。
- Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without tampering by an attacker.
- 允许客户端和服务器验证其对等方是否计算了相同的安全参数，以及握手是否在未被攻击者篡改的情况下发生。
Note that higher layers should not be overly reliant on whether TLS always negotiates the strongest possible connection between two peers. There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support. The protocol has been designed to minimize this risk, but there are still attacks available: for example, an attacker could block access to the port a secure service runs on, or attempt to get the peers to negotiate an unauthenticated connection. The fundamental rule is that higher levels must be cognizant of what their security requirements are and never transmit information over a channel less secure than what they require. The TLS protocol is secure in that any cipher suite offers its promised level of security: if you negotiate 3DES with a 1024-bit RSA key exchange with a host whose certificate you have verified, you can expect to be that secure.
请注意，更高层不应过度依赖TLS是否始终协商两个对等方之间可能最强的连接。中间人攻击者可以通过多种方式试图使两个实体下降到它们支持的最不安全的方法。该协议旨在将此风险降至最低，但仍然存在可用的攻击：例如，攻击者可能会阻止对运行安全服务的端口的访问，或试图让对等方协商未经验证的连接。基本规则是，更高级别的人员必须了解他们的安全要求是什么，并且决不能通过低于他们要求的安全性的通道传输信息。TLS协议是安全的，因为任何密码套件都提供其承诺的安全级别：如果您与已验证其证书的主机协商使用1024位RSA密钥交换的3DE，那么您可以期望是安全的。
These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a ClientHello message to which the server must respond with a ServerHello message, or else a fatal error will occur and the connection will fail. The ClientHello and ServerHello are used to establish security enhancement capabilities between client and server. The ClientHello and ServerHello establish the following attributes: Protocol Version, Session ID, Cipher Suite, and Compression Method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random.
这些目标是通过握手协议实现的，握手协议可以概括如下：客户端发送ClientHello消息，服务器必须用ServerHello消息响应该消息，否则将发生致命错误，连接将失败。ClientHello和ServerHello用于在客户端和服务器之间建立安全增强功能。ClientHello和ServerHello建立以下属性：协议版本、会话ID、密码套件和压缩方法。此外，还会生成并交换两个随机值：ClientHello.random和ServerHello.random。
The actual key exchange uses up to four messages: the server Certificate, the ServerKeyExchange, the client Certificate, and the ClientKeyExchange. New key exchange methods can be created by specifying a format for these messages and by defining the use of the messages to allow the client and server to agree upon a shared secret. This secret MUST be quite long; currently defined key exchange methods exchange secrets that range from 46 bytes upwards.
实际的密钥交换最多使用四条消息：服务器证书、ServerKeyExchange、客户端证书和ClientKeyExchange。新的密钥交换方法可以通过为这些消息指定格式和定义消息的使用来创建，以允许客户端和服务器就共享秘密达成一致。这个秘密一定很长；当前定义的密钥交换方法交换46字节以上的秘密。
Following the hello messages, the server will send its certificate in a Certificate message if it is to be authenticated. Additionally, a ServerKeyExchange message may be sent, if it is required (e.g., if the server has no certificate, or if its certificate is for signing only). If the server is authenticated, it may request a certificate from the client, if that is appropriate to the cipher suite selected. Next, the server will send the ServerHelloDone message, indicating that the hello-message phase of the handshake is complete. The server will then wait for a client response. If the server has sent a CertificateRequest message, the client MUST send the Certificate message. The ClientKeyExchange message is now sent, and the content of that message will depend on the public key algorithm selected between the ClientHello and the ServerHello. If the client has sent a certificate with signing ability, a digitally-signed CertificateVerify message is sent to explicitly verify possession of the private key in the certificate.
在hello消息之后，如果要对其进行身份验证，服务器将在证书消息中发送其证书。此外，如果需要，可以发送ServerKeyExchange消息（例如，如果服务器没有证书，或者如果其证书仅用于签名）。如果服务器经过身份验证，它可能会从客户端请求证书（如果该证书适用于所选的密码套件）。接下来，服务器将发送ServerHelloDone消息，指示握手的hello消息阶段已完成。然后，服务器将等待客户端响应。如果服务器已发送CertificateRequest消息，则客户端必须发送证书消息。现在发送ClientKeyExchange消息，该消息的内容将取决于ClientHello和ServerHello之间选择的公钥算法。如果客户端已发送具有签名功能的证书，则会发送数字签名的CertificateVerify消息，以明确验证证书中私钥的拥有情况。
At this point, a ChangeCipherSpec message is sent by the client, and the client copies the pending Cipher Spec into the current Cipher Spec. The client then immediately sends the Finished message under the new algorithms, keys, and secrets. In response, the server will send its own ChangeCipherSpec message, transfer the pending to the current Cipher Spec, and send its Finished message under the new Cipher Spec. At this point, the handshake is complete, and the client and server may begin to exchange application layer data. (See flow chart below.) Application data MUST NOT be sent prior to the completion of the first handshake (before a cipher suite other than TLS_NULL_WITH_NULL_NULL is established).
此时，客户机发送ChangeCipherSpec消息，客户机将挂起的密码规范复制到当前密码规范中。然后，客户机立即根据新算法、密钥和机密发送完成的消息。作为响应，服务器将发送其自己的ChangeCipherSpec消息，将挂起的消息传输到当前密码规范，并根据新密码规范发送其完成的消息。此时，握手完成，客户端和服务器可能开始交换应用层数据。（参见下面的流程图。）在第一次握手完成之前（在建立除TLS_NULL_和_NULL_NULL以外的密码套件之前），不得发送应用程序数据。
Client Server
客户端服务器
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Figure 1. Message flow for a full handshake
图1。完整握手的消息流
* Indicates optional or situation-dependent messages that are not always sent.
* 指示并非始终发送的可选消息或情况相关消息。
Note: To help avoid pipeline stalls, ChangeCipherSpec is an independent TLS protocol content type, and is not actually a TLS handshake message.
注意：为了帮助避免管道暂停，ChangeCipherSpec是一种独立的TLS协议内容类型，实际上不是TLS握手消息。
When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters), the message flow is as follows:
当客户端和服务器决定恢复上一个会话或复制现有会话（而不是协商新的安全参数）时，消息流如下所示：
The client sends a ClientHello using the Session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. At this point, both client and server MUST send ChangeCipherSpec messages and proceed directly to Finished messages. Once the re-establishment is complete, the client and server MAY begin to exchange application layer data. (See flow chart below.) If a Session ID match is not found, the server generates a new session ID, and the TLS client and server perform a full handshake.
客户端使用要恢复的会话的会话ID发送ClientHello。然后服务器检查其会话缓存是否匹配。如果找到匹配项，并且服务器愿意在指定的会话状态下重新建立连接，它将发送具有相同会话ID值的ServerHello。此时，客户端和服务器都必须发送ChangeCipherSpec消息，并直接处理完成的消息。一旦重建完成，客户端和服务器就可以开始交换应用层数据。（请参阅下面的流程图。）如果找不到会话ID匹配，服务器将生成新的会话ID，TLS客户端和服务器将执行完全握手。
Client Server
客户端服务器
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Figure 2. Message flow for an abbreviated handshake
图2。简短握手的消息流
The contents and significance of each message will be presented in detail in the following sections.
以下各节将详细介绍每条信息的内容和意义。
The TLS Handshake Protocol is one of the defined higher-level clients of the TLS Record Protocol. This protocol is used to negotiate the secure attributes of a session. Handshake messages are supplied to the TLS record layer, where they are encapsulated within one or more TLSPlaintext structures, which are processed and transmitted as specified by the current active session state.
TLS握手协议是TLS记录协议定义的高级客户端之一。此协议用于协商会话的安全属性。握手消息被提供给TLS记录层，在TLS记录层中，它们被封装在一个或多个TLSPlaintext结构中，并按照当前活动会话状态的指定进行处理和传输。
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
The handshake protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order results in a fatal error. Unneeded handshake messages can be omitted, however. Note one exception to the ordering: the Certificate message is used twice in the handshake (from server to client, then from client to server), but described only in its first position. The one message that is not bound by these ordering rules is the HelloRequest message, which can be sent at any time, but which SHOULD be ignored by the client if it arrives in the middle of a handshake.
握手协议消息按其必须发送的顺序显示在下面；以意外顺序发送握手消息会导致致命错误。然而，不需要的握手信息可以省略。注意排序的一个例外：证书消息在握手中使用了两次（从服务器到客户端，然后从客户端到服务器），但仅在第一个位置进行描述。不受这些排序规则约束的一个消息是HELRORQuestMeST消息，该消息可以在任何时间发送，但如果客户端在握手期间到达，则应该忽略该消息。
New handshake message types are assigned by IANA as described in Section 12.
新的握手消息类型由IANA分配，如第12节所述。
The hello phase messages are used to exchange security enhancement capabilities between the client and server. When a new session begins, the record layer's connection state encryption, hash, and compression algorithms are initialized to null. The current connection state is used for renegotiation messages.
hello阶段消息用于在客户端和服务器之间交换安全增强功能。当新会话开始时，记录层的连接状态加密、哈希和压缩算法将初始化为null。当前连接状态用于重新协商消息。
When this message will be sent:
将发送此消息的时间：
The HelloRequest message MAY be sent by the server at any time.
服务器可以随时发送HelloRequest消息。
Meaning of this message:
此信息的含义：
HelloRequest is a simple notification that the client should begin the negotiation process anew. In response, the client should send a ClientHello message when convenient. This message is not intended to establish which side is the client or server but merely to initiate a new negotiation. Servers SHOULD NOT send a HelloRequest immediately upon the client's initial connection. It is the client's job to send a ClientHello at that time.
HelloRequest是一个简单的通知，客户机应该重新开始协商过程。作为响应，客户机应在方便时发送ClientHello消息。此消息的目的不是确定哪一方是客户端或服务器，而只是启动新的协商。服务器不应在客户端初始连接时立即发送HelloRequest。客户当时的工作是发送ClientHello。
This message will be ignored by the client if the client is currently negotiating a session. This message MAY be ignored by the client if it does not wish to renegotiate a session, or the client may, if it wishes, respond with a no_renegotiation alert. Since handshake messages are intended to have transmission precedence over application data, it is expected that the negotiation will begin before no more than a few records are received from the client. If the server sends a HelloRequest but does not receive a ClientHello in response, it may close the connection with a fatal alert.
如果客户端当前正在协商会话，则客户端将忽略此消息。如果客户端不希望重新协商会话，则可能会忽略此消息，或者如果客户端愿意，可能会以“无重新协商”警报进行响应。由于握手消息的传输优先于应用程序数据，因此在从客户端接收到不超过几个记录之前，协商将开始。如果服务器发送HelloRequest但未收到ClientHello响应，则可能会通过致命警报关闭连接。
After sending a HelloRequest, servers SHOULD NOT repeat the request until the subsequent handshake negotiation is complete.
发送HelloRequest后，服务器不应重复请求，直到后续握手协商完成。
Structure of this message:
此消息的结构：
struct { } HelloRequest;
struct { } HelloRequest;
This message MUST NOT be included in the message hashes that are maintained throughout the handshake and used in the Finished messages and the certificate verify message.
此消息不得包含在整个握手过程中维护的消息哈希中，也不得用于完成的消息和证书验证消息中。
When this message will be sent:
将发送此消息的时间：
When a client first connects to a server, it is required to send the ClientHello as its first message. The client can also send a ClientHello in response to a HelloRequest or on its own initiative in order to renegotiate the security parameters in an existing connection.
当客户机第一次连接到服务器时，需要将ClientHello作为其第一条消息发送。客户端还可以发送ClientHello以响应HelloRequest或主动发送，以便重新协商现有连接中的安全参数。
Structure of this message:
此消息的结构：
The ClientHello message includes a random structure, which is used later in the protocol.
ClientHello消息包含一个随机结构，该结构稍后将在协议中使用。
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
gmt_unix_time The current time and date in standard UNIX 32-bit format (seconds since the midnight starting Jan 1, 1970, UTC, ignoring leap seconds) according to the sender's internal clock. Clocks are not required to be set correctly by the basic TLS protocol; higher-level or application protocols may define additional requirements. Note that, for historical reasons, the data element is named using GMT, the predecessor of the current worldwide time base, UTC.
gmt_unix_time标准unix 32位格式的当前时间和日期（自1970年1月1日午夜开始的秒，UTC，忽略闰秒），根据发送方的内部时钟。基本TLS协议不要求正确设置时钟；更高级别的协议或应用程序协议可能会定义其他要求。请注意，出于历史原因，数据元素使用GMT命名，GMT是当前全球时基UTC的前身。
random_bytes 28 bytes generated by a secure random number generator.
随机字节由安全随机数生成器生成的28个字节。
The ClientHello message includes a variable-length session identifier. If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier MAY be from an earlier connection,
ClientHello消息包含一个可变长度的会话标识符。如果不为空，则该值标识同一客户端和服务器之间的会话，客户端希望重用其安全参数。会话标识符可以来自较早的连接，
this connection, or from another currently active connection. The second option is useful if the client only wishes to update the random structures and derived values of a connection, and the third option makes it possible to establish several independent secure connections without repeating the full handshake protocol. These independent connections may occur sequentially or simultaneously; a SessionID becomes valid when the handshake negotiating it completes with the exchange of Finished messages and persists until it is removed due to aging or because a fatal error was encountered on a connection associated with the session. The actual contents of the SessionID are defined by the server.
此连接，或来自另一个当前活动的连接。如果客户端只希望更新连接的随机结构和派生值，则第二个选项很有用，第三个选项可以在不重复完整握手协议的情况下建立多个独立的安全连接。这些独立的连接可以连续或同时发生；当握手协商完成并交换完成的消息时，SessionID将变为有效，并持续存在，直到由于老化或与会话关联的连接上遇到致命错误而将其删除。SessionID的实际内容由服务器定义。
opaque SessionID<0..32>;
opaque SessionID<0..32>;
Warning: Because the SessionID is transmitted without encryption or immediate MAC protection, servers MUST NOT place confidential information in session identifiers or let the contents of fake session identifiers cause any breach of security. (Note that the content of the handshake as a whole, including the SessionID, is protected by the Finished messages exchanged at the end of the handshake.)
警告：由于SessionID是在没有加密或立即MAC保护的情况下传输的，因此服务器不得在会话标识符中放置机密信息，也不得让虚假会话标识符的内容造成任何安全漏洞。（请注意，整个握手的内容（包括SessionID）受握手结束时交换的完成消息的保护。）
The cipher suite list, passed from the client to the server in the ClientHello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). Each cipher suite defines a key exchange algorithm, a bulk encryption algorithm (including secret key length), a MAC algorithm, and a PRF. The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection. If the list contains cipher suites the server does not recognize, support, or wish to use, the server MUST ignore those cipher suites, and process the remaining ones as usual.
密码套件列表在ClientHello消息中从客户机传递到服务器，包含客户机支持的密码算法组合，按照客户机的首选项（首选项优先）排列。每个密码套件定义一个密钥交换算法、一个批量加密算法（包括密钥长度）、一个MAC算法和一个PRF。服务器将选择密码套件，如果没有可接受的选项，则返回握手失败警报并关闭连接。如果列表包含服务器不识别、不支持或不希望使用的密码套件，则服务器必须忽略这些密码套件，并像往常一样处理其余的密码套件。
uint8 CipherSuite[2]; /* Cryptographic suite selector */
uint8 CipherSuite[2]; /* Cryptographic suite selector */
The ClientHello includes a list of compression algorithms supported by the client, ordered according to the client's preference.
ClientHello包括一个客户机支持的压缩算法列表，根据客户机的偏好排序。
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
TLS allows extensions to follow the compression_methods field in an extensions block. The presence of extensions can be detected by determining whether there are bytes following the compression_methods 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允许扩展遵循扩展块中的压缩方法字段。可以通过确定ClientHello末尾是否有紧跟压缩方法的字节来检测扩展的存在。请注意，这种检测可选数据的方法不同于具有可变长度字段的常规TLS方法，但它用于在定义扩展之前与TLS兼容。
client_version The version of the TLS protocol by which the client wishes to communicate during this session. This SHOULD be the latest (highest valued) version supported by the client. For this version of the specification, the version will be 3.3 (see Appendix E for details about backward compatibility).
客户端版本客户端希望在此会话期间通信的TLS协议版本。这应该是客户端支持的最新（最高值）版本。对于本规范版本，版本为3.3（有关向后兼容性的详细信息，请参见附录E）。
random A client-generated random structure.
随机客户端生成的随机结构。
session_id The ID of a session the client wishes to use for this connection. This field is empty if no session_id is available, or if the client wishes to generate new security parameters.
会话\u id客户端希望用于此连接的会话的id。如果没有可用的会话id，或者客户端希望生成新的安全参数，则此字段为空。
cipher_suites This is a list of the cryptographic options supported by the client, with the client's first preference first. If the session_id field is not empty (implying a session resumption request), this vector MUST include at least the cipher_suite from that session. Values are defined in Appendix A.5.
cipher_suites这是客户机支持的加密选项列表，首先是客户机的首选项。如果session_id字段不为空（意味着会话恢复请求），则此向量必须至少包含来自该会话的密码套件。数值在附录A.5中定义。
compression_methods This is a list of the compression methods supported by the client, sorted by client preference. If the session_id field is not empty (implying a session resumption request), it MUST include the
压缩方法这是客户机支持的压缩方法列表，按客户机首选项排序。如果session_id字段不是空的（意味着会话恢复请求），它必须包括
compression_method from that session. This vector MUST contain, and all implementations MUST support, CompressionMethod.null. Thus, a client and server will always be able to agree on a compression method.
compression_method from that session. This vector MUST contain, and all implementations MUST support, CompressionMethod.null. Thus, a client and server will always be able to agree on a compression method.translate error, please retry
extensions Clients MAY request extended functionality from servers by sending data in the extensions field. The actual "Extension" format is defined in Section 7.4.1.4.
extensions客户端可以通过在extensions字段中发送数据从服务器请求扩展功能。第7.4.1.4节定义了实际的“扩展”格式。
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. A server MUST accept ClientHello messages both with and without the extensions field, and (as for all other messages) it MUST check that the amount of data in the message precisely matches one of these formats; if not, then it MUST send a fatal "decode_error" alert.
如果客户端使用扩展请求附加功能，而服务器未提供此功能，则客户端可能会中止握手。服务器必须接受包含和不包含extensions字段的ClientHello消息，并且（对于所有其他消息），它必须检查消息中的数据量是否与这些格式中的一种完全匹配；如果没有，则必须发送致命的“解码错误”警报。
After sending the ClientHello message, the client waits for a ServerHello message. Any handshake message returned by the server, except for a HelloRequest, is treated as a fatal error.
发送ClientHello消息后，客户机等待ServerHello消息。服务器返回的任何握手消息（HelloRequest除外）都被视为致命错误。
When this message will be sent:
将发送此消息的时间：
The server will send this message in response to a ClientHello message when it was able to find an acceptable set of algorithms. If it cannot find such a match, it will respond with a handshake failure alert.
当服务器能够找到一组可接受的算法时，它将发送此消息以响应ClientHello消息。如果找不到这样的匹配项，它将发出握手失败警报。
Structure of this message:
此消息的结构：
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
The presence of extensions can be detected by determining whether there are bytes following the compression_method field at the end of the ServerHello.
可以通过确定ServerHello末尾的compression_method字段后面是否有字节来检测是否存在扩展。
server_version This field will contain the lower of that suggested by the client in the client hello and the highest supported by the server. For this version of the specification, the version is 3.3. (See Appendix E for details about backward compatibility.)
服务器版本此字段将包含客户端hello中客户端建议的较低版本和服务器支持的最高版本。对于本规范版本，版本为3.3。（有关向后兼容性的详细信息，请参见附录E。）
random This structure is generated by the server and MUST be independently generated from the ClientHello.random.
随机此结构由服务器生成，必须独立于ClientHello.random生成。
session_id This is the identity of the session corresponding to this connection. If the ClientHello.session_id was non-empty, the server will look in its session cache for a match. If a match is found and the server is willing to establish the new connection using the specified session state, the server will respond with the same value as was supplied by the client. This indicates a resumed session and dictates that the parties must proceed directly to the Finished messages. Otherwise, this field will contain a different value identifying the new session. The server may return an empty session_id to indicate that the session will not be cached and therefore cannot be resumed. If a session is resumed, it must be resumed using the same cipher suite it was originally negotiated with. Note that there is no requirement that the server resume any session even if it had formerly provided a session_id. Clients MUST be prepared to do a full negotiation -- including negotiating new cipher suites -- during any handshake.
会话\u id这是与此连接对应的会话的标识。如果ClientHello.session_id非空，服务器将在其会话缓存中查找匹配项。如果找到匹配项，并且服务器愿意使用指定的会话状态建立新连接，则服务器将使用客户端提供的相同值进行响应。这表示会话已恢复，并指示各方必须直接进入已完成的消息。否则，此字段将包含标识新会话的不同值。服务器可能会返回一个空会话id，以指示该会话不会被缓存，因此无法恢复。如果会话恢复，则必须使用最初与之协商的密码套件恢复会话。请注意，即使服务器以前提供了会话id，也不要求服务器恢复任何会话。客户端必须准备在任何握手过程中进行完整协商，包括协商新的密码套件。
cipher_suite The single cipher suite selected by the server from the list in ClientHello.cipher_suites. For resumed sessions, this field is the value from the state of the session being resumed.
cipher_suite服务器从ClientHello.cipher_suite中的列表中选择的单个密码套件。对于恢复的会话，此字段是正在恢复的会话状态的值。
compression_method The single compression algorithm selected by the server from the list in ClientHello.compression_methods. For resumed sessions, this field is the value from the resumed session state.
压缩方法服务器从ClientHello.compression\u方法列表中选择的单一压缩算法。对于恢复的会话，此字段是恢复的会话状态的值。
extensions A list of extensions. Note that only extensions offered by the client can appear in the server's list.
扩展：扩展的列表。请注意，只有客户端提供的扩展才能出现在服务器的列表中。
The extension format is:
扩展格式为：
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 {
signature_algorithms(13), (65535)
} ExtensionType;
enum {
signature_algorithms(13), (65535)
} ExtensionType;
Here:
在这里：
- "extension_type" identifies the particular extension type.
- “扩展类型”标识特定的扩展类型。
- "extension_data" contains information specific to the particular extension type.
- “扩展数据”包含特定于特定扩展类型的信息。
The initial set of extensions is defined in a companion document [TLSEXT]. The list of extension types is maintained by IANA as described in Section 12.
初始扩展集在附带文档[TLSEXT]中定义。扩展类型列表由IANA维护，如第12节所述。
An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. If a client receives an extension type in ServerHello that it did not request in the associated ClientHello, it MUST abort the handshake with an unsupported_extension fatal alert.
扩展类型不得出现在ServerHello中，除非相应的ClientHello中出现了相同的扩展类型。如果客户端在ServerHello中接收到扩展类型，而它在关联的ClientHello中没有请求该扩展类型，则它必须使用不受支持的扩展致命警报中止握手。
Nonetheless, "server-oriented" extensions may be provided in the future within this framework. Such an extension (say, of type x) would require the client to first send an extension of type x in a ClientHello with empty extension_data to indicate that it supports the extension type. In this case, the client is offering the capability to understand the extension type, and the server is taking the client up on its offer.
尽管如此，“面向服务器”的扩展将来可能会在这个框架内提供。这样的扩展（例如，类型x）将要求客户机首先在ClientHello中发送一个类型x的扩展，其中包含空的扩展_数据，以表明它支持该扩展类型。在这种情况下，客户机提供了理解扩展类型的功能，而服务器接受了客户机的提供。
When multiple extensions of different types are present in the ClientHello or ServerHello messages, the extensions MAY appear in any order. There MUST NOT be more than one extension of the same type.
当ClientHello或ServerHello消息中存在多个不同类型的扩展时，这些扩展可能以任意顺序出现。同一类型的扩展不能超过一个。
Finally, note that extensions can be sent both when starting a new session and when requesting session resumption. Indeed, a client that requests session resumption does not in general know whether the server will accept this request, and therefore it SHOULD send the same extensions as it would send if it were not attempting resumption.
最后，请注意，在启动新会话和请求会话恢复时都可以发送扩展。实际上，请求会话恢复的客户端通常不知道服务器是否会接受此请求，因此它应该发送与不尝试恢复时相同的扩展名。
In general, the specification of each extension type needs to describe the effect of the extension both during full handshake and session resumption. Most current TLS extensions are relevant only when a session is initiated: when an older session is resumed, the server does not process these extensions in Client Hello, and does not include them in Server Hello. However, some extensions may specify different behavior during session resumption.
通常，每种扩展类型的规范都需要描述扩展在完全握手和会话恢复期间的效果。大多数当前TLS扩展仅在会话启动时才相关：当旧会话恢复时，服务器不会在客户端Hello中处理这些扩展，也不会在服务器Hello中包含它们。但是，某些扩展可能在会话恢复期间指定不同的行为。
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, 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.
通常，扩展字段包含在完成的消息哈希的输入中就足够了，但是当扩展更改握手阶段发送的消息的含义时，需要格外小心。设计者和实现者应该知道，在握手经过身份验证之前，主动攻击者可以修改消息并插入、删除或替换扩展。
- It would be technically possible to use extensions to change major aspects of the design of TLS; for example the design of cipher suite negotiation. This is not recommended; it would be more appropriate to define a new version of TLS -- particularly since the TLS handshake algorithms have specific protection against version rollback attacks based on the version number, and the possibility of version rollback should be a significant consideration in any major design change.
- 技术上可以使用扩展来改变TLS设计的主要方面；例如密码组协商的设计。不建议这样做；定义TLS的新版本更合适——特别是因为TLS握手算法具有基于版本号的版本回滚攻击的特定保护，并且版本回滚的可能性应该是任何重大设计更改的重要考虑因素。
The client uses the "signature_algorithms" extension to indicate to the server which signature/hash algorithm pairs may be used in digital signatures. The "extension_data" field of this extension contains a "supported_signature_algorithms" value.
客户端使用“signature_algorithms”扩展向服务器指示哪些签名/哈希算法对可用于数字签名。此扩展的“扩展\u数据”字段包含“受支持的\u签名\u算法”值。
enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
enum {
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
SignatureAlgorithm;
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
SignatureAlgorithm;
struct {
HashAlgorithm hash;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
struct {
HashAlgorithm hash;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-2>;
Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify. The values are indicated in descending order of preference.
每个SignatureAndHashAlgorithm值都列出了客户端愿意验证的单个哈希/签名对。这些值按首选项的降序显示。
Note: Because not all signature algorithms and hash algorithms may be accepted by an implementation (e.g., DSA with SHA-1, but not SHA-256), algorithms here are listed in pairs.
注：由于并非所有签名算法和散列算法都可以被实现所接受（例如，带有SHA-1的DSA，但不包括SHA-256），因此这里的算法成对列出。
hash This field indicates the hash algorithm which may be used. The values indicate support for unhashed data, MD5 [MD5], SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The "none" value is provided for future extensibility, in case of a signature algorithm which does not require hashing before signing.
散列此字段表示可以使用的散列算法。这些值分别表示对未剪切数据MD5[MD5]、SHA-1、SHA-224、SHA-256、SHA-384和SHA-512[SHS]的支持。如果签名算法在签名之前不需要散列，则提供“none”值是为了将来的扩展性。
signature This field indicates the signature algorithm that may be used. The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The "anonymous" value is meaningless in this context but used in Section 7.4.3. It MUST NOT appear in this extension.
签名此字段表示可能使用的签名算法。这些值分别表示匿名签名RSASSA-PKCS1-v1_5[PKCS1]和DSA[DSS]以及ECDSA[ECDSA]。“匿名”值在此上下文中没有意义，但在第7.4.3节中使用。它不能出现在此扩展中。
The semantics of this extension are somewhat complicated because the cipher suite indicates permissible signature algorithms but not hash algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
此扩展的语义有些复杂，因为密码套件指示允许的签名算法，而不是哈希算法。第7.4.2节和第7.4.3节描述了适当的规则。
If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key exchange), it MUST send the
如果客户端仅支持默认哈希和签名算法（在本节中列出），它可能会忽略签名算法扩展。如果客户端不支持默认算法，或支持其他哈希和签名算法（并且愿意使用它们来验证服务器发送的消息，即服务器证书和服务器密钥交换），则必须发送
signature_algorithms extension, listing the algorithms it is willing to accept.
签名算法扩展，列出它愿意接受的算法。
If the client does not send the signature_algorithms extension, the server MUST do the following:
如果客户端未发送签名算法扩展，服务器必须执行以下操作：
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent the value {sha1,rsa}.
- 如果协商密钥交换算法是（RSA、DHE_RSA、DH_RSA、RSA_PSK、ECDH_RSA、ECDHE_RSA）中的一种，则表现为客户端发送了值{sha1，RSA}。
- If the negotiated key exchange algorithm is one of (DHE_DSS, DH_DSS), behave as if the client had sent the value {sha1,dsa}.
- 如果协商密钥交换算法是（DHE_-DSS，DH_-DSS）之一，则其行为就像客户端发送了值{sha1，dsa}。
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA, ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
- 如果协商的密钥交换算法是（ECDH_ECDSA，ECDHE_ECDSA）之一，则其行为就像客户端发送了值{sha1，ECDSA}。
Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA-1.
注意：这是TLS 1.1的一个变化，在TLS 1.1中没有明确的规则，但实际上可以假设对等方支持MD5和SHA-1。
Note: this extension is not meaningful for TLS versions prior to 1.2. Clients MUST NOT offer it if they are offering prior versions. However, even if clients do offer it, the rules specified in [TLSEXT] require servers to ignore extensions they do not understand.
注意：此扩展对于1.2之前的TLS版本没有意义。如果客户提供以前的版本，则不得提供。然而，即使客户端确实提供了它，[TLSEXT]中指定的规则要求服务器忽略它们不理解的扩展。
Servers MUST NOT send this extension. TLS servers MUST support receiving this extension.
服务器不能发送此扩展名。TLS服务器必须支持接收此扩展。
When performing session resumption, this extension is not included in Server Hello, and the server ignores the extension in Client Hello (if present).
执行会话恢复时，此扩展不包括在服务器Hello中，服务器将忽略客户端Hello中的扩展（如果存在）。
When this message will be sent:
将发送此消息的时间：
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 DH_anon). This message will always immediately follow the ServerHello message.
每当约定的密钥交换方法使用证书进行身份验证时，服务器必须发送证书消息（这包括本文档中定义的除DH_anon之外的所有密钥交换方法）。此消息将始终紧跟在ServerHello消息之后。
Meaning of this message:
此信息的含义：
This message conveys the server's certificate chain to the client.
此消息将服务器的证书链传送到客户端。
The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm and any negotiated extensions.
证书必须适合协商密码套件的密钥交换算法和任何协商扩展。
Structure of this message:
此消息的结构：
opaque ASN.1Cert<1..2^24-1>;
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
certificate_list This is a sequence (chain) of certificates. The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
证书列表这是一个证书序列（链）。发件人的证书必须排在列表的第一位。下列证书必须直接证明其前面的证书。由于证书验证要求独立分发根密钥，因此可以从链中省略指定根证书颁发机构的自签名证书，前提是远程端必须已经拥有该证书，以便在任何情况下对其进行验证。
The same message type and structure will be used for the client's response to a certificate request message. Note that a client MAY send no certificates if it does not have an appropriate certificate to send in response to the server's authentication request.
客户端对证书请求消息的响应将使用相同的消息类型和结构。请注意，如果客户端没有响应服务器的身份验证请求而发送的适当证书，则客户端可能不会发送任何证书。
Note: PKCS #7 [PKCS7] is not used as the format for the certificate vector because PKCS #6 [PKCS6] extended certificates are not used. Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task of parsing the list more difficult.
注意：PKCS#7[PKCS7]未用作证书向量的格式，因为未使用PKCS#6[PKCS6]扩展证书。此外，PKCS#7定义了一个集合而不是一个序列，这使得解析列表的任务更加困难。
The following rules apply to the certificates sent by the server:
以下规则适用于服务器发送的证书：
- The certificate type MUST be X.509v3, unless explicitly negotiated otherwise (e.g., [TLSPGP]).
- 除非另有明确协商（例如[TLSPGP]），否则证书类型必须为X.509v3。
- The end entity certificate's public key (and associated restrictions) MUST be compatible with the selected key exchange algorithm.
- 终端实体证书的公钥（和相关限制）必须与所选密钥交换算法兼容。
Key Exchange Alg. Certificate Key Type
密钥交换Alg。证书密钥类型
RSA RSA public key; the certificate MUST allow the RSA_PSK key to be used for encryption (the keyEncipherment bit MUST be set if the key usage extension is present). Note: RSA_PSK is defined in [TLSPSK].
RSA公钥；证书必须允许RSA_PSK密钥用于加密（如果存在密钥使用扩展，则必须设置密钥加密位）。注：RSA_PSK在[TLSPSK]中定义。
DHE_RSA RSA public key; the certificate MUST allow the ECDHE_RSA key to be used for signing (the digitalSignature bit MUST be set if the key usage extension is present) with the signature scheme and hash algorithm that will be employed in the server key exchange message. Note: ECDHE_RSA is defined in [TLSECC].
DHE_RSA公钥；证书必须允许ECDHE_RSA密钥用于签名（如果存在密钥使用扩展，则必须设置数字签名位），签名方案和哈希算法将在服务器密钥交换消息中使用。注：ECDHE_RSA在[TLSECC]中定义。
DHE_DSS DSA public key; the certificate MUST allow the key to be used for signing with the hash algorithm that will be employed in the server key exchange message.
DHE_DSS DSA公钥；证书必须允许密钥用于使用将在服务器密钥交换消息中使用的哈希算法进行签名。
DH_DSS Diffie-Hellman public key; the keyAgreement bit DH_RSA MUST be set if the key usage extension is present.
DH_DSS Diffie-Hellman公钥；如果存在密钥使用扩展，则必须设置密钥协议位DH_RSA。
ECDH_ECDSA ECDH-capable public key; the public key MUST ECDH_RSA use a curve and point format supported by the client, as described in [TLSECC].
ECDH_ECDSA支持ECDH的公钥；公钥必须使用客户机支持的曲线和点格式，如[TLSECC]中所述。
ECDHE_ECDSA ECDSA-capable public key; the certificate MUST allow the key to be used for signing with the hash algorithm that will be employed in the server key exchange message. The public key MUST use a curve and point format supported by the client, as described in [TLSECC].
ECDHE_ECDSA支持ECDSA的公钥；证书必须允许密钥用于使用将在服务器密钥交换消息中使用的哈希算法进行签名。公钥必须使用客户端支持的曲线和点格式，如[TLSECC]中所述。
- The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are used to guide certificate selection.
- “服务器名称”和“可信证书密钥”扩展[TLSEXT]用于指导证书选择。
If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies 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 a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical.
如果客户端提供了“签名算法”扩展，那么服务器提供的所有证书都必须由该扩展中出现的哈希/签名算法对签名。请注意，这意味着可以使用不同的签名算法（例如，使用DSA密钥签名的RSA密钥）对包含一个签名算法的密钥的证书进行签名。这与TLS 1.1不同，TLS 1.1要求算法相同。请注意，这还意味着DH_DSS、DH_RSA、ECDH_ECDSA和ECDH_RSA密钥交换算法不限制用于签署证书的算法。固定DH证书可以使用扩展中出现的任何哈希/签名算法对进行签名。DH_DSS、DH_RSA、ECDH_ECDSA和ECDH_RSA的名称是历史名称。
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, etc.). If the server has a single certificate, it SHOULD attempt to validate that it meets these criteria.
如果服务器有多个证书，它将根据上述标准（以及其他标准，如传输层端点、本地配置和首选项等）选择其中一个证书。如果服务器只有一个证书，它应该尝试验证它是否满足这些条件。
Note that there are certificates that use algorithms and/or algorithm combinations that cannot be currently used with TLS. For example, a certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in SubjectPublicKeyInfo) cannot be used because TLS defines no corresponding signature algorithm.
请注意，有些证书使用当前无法与TLS一起使用的算法和/或算法组合。例如，不能使用具有RSASSA-PSS签名密钥（SubjectPublicKeyInfo中的id RSASSA PSS OID）的证书，因为TLS没有定义相应的签名算法。
As cipher suites that specify new key exchange methods are specified for the TLS protocol, they will imply the certificate format and the required encoded keying information.
由于为TLS协议指定了指定新密钥交换方法的密码套件，它们将暗示证书格式和所需的编码密钥信息。
When this message will be sent:
将发送此消息的时间：
This message will be sent immediately after the server Certificate message (or the ServerHello message, if this is an anonymous negotiation).
此消息将在服务器证书消息（或ServerHello消息，如果这是匿名协商）之后立即发送。
The ServerKeyExchange message is sent by the server only when the server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret. This is true for the following key exchange methods:
只有当服务器证书消息（如果已发送）包含的数据不足以允许客户端交换premaster机密时，服务器才会发送ServerKeyExchange消息。这适用于以下密钥交换方法：
DHE_DSS DHE_RSA DH_anon
DHE_DSS DHE_RSA DH_anon
It is not legal to send the ServerKeyExchange message for the following key exchange methods:
为以下密钥交换方法发送ServerKeyExchange消息是不合法的：
RSA DH_DSS DH_RSA
RSA DH_DSS DH_RSA
Other key exchange algorithms, such as those defined in [TLSECC], MUST specify whether the ServerKeyExchange message is sent or not; and if the message is sent, its contents.
其他密钥交换算法，如[TLSECC]中定义的算法，必须指定是否发送ServerKeyExchange消息；如果消息被发送，它的内容。
Meaning of this message:
此信息的含义：
This message conveys cryptographic information to allow the client to communicate the premaster secret: a Diffie-Hellman public key with which the client can complete a key exchange (with the result being the premaster secret) or a public key for some other algorithm.
此消息传递密码信息，以允许客户端传递premaster机密：Diffie-Hellman公钥，客户端可以使用该公钥完成密钥交换（结果为premaster机密）或某些其他算法的公钥。
Structure of this message:
此消息的结构：
enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} KeyExchangeAlgorithm;
enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} KeyExchangeAlgorithm;
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
dh_p The prime modulus used for the Diffie-Hellman operation.
dh_p用于Diffie-Hellman运算的素模。
dh_g The generator used for the Diffie-Hellman operation.
dh_g用于Diffie-Hellman操作的发电机。
dh_Ys The server's Diffie-Hellman public value (g^X mod p).
dh_Ys服务器的Diffie-Hellman公共值（g^X mod p）。
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
case rsa:
case dh_dss:
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
/* may be extended, e.g., for ECDH -- see [TLSECC] */
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
case rsa:
case dh_dss:
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
/* may be extended, e.g., for ECDH -- see [TLSECC] */
};
} ServerKeyExchange;
params The server's key exchange parameters.
params服务器的密钥交换参数。
signed_params For non-anonymous key exchanges, a signature over the server's key exchange parameters.
signed_params用于非匿名密钥交换，是服务器密钥交换参数上的签名。
If the client has offered the "signature_algorithms" extension, the signature algorithm and hash algorithm MUST be a pair listed in that extension. Note that there is a possibility for inconsistencies here. For instance, the client might offer DHE_DSS key exchange but omit any DSA pairs from its "signature_algorithms" extension. In order to negotiate correctly, the server MUST check any candidate cipher suites against the "signature_algorithms" extension before selecting them. This is somewhat inelegant but is a compromise designed to minimize changes to the original cipher suite design.
如果客户端提供了“签名算法”扩展，则签名算法和哈希算法必须是该扩展中列出的一对。请注意，此处可能存在不一致的情况。例如，客户端可能提供DHE_DSS密钥交换，但从其“signature_algorithms”扩展中省略任何DSA对。为了正确协商，服务器必须在选择任何候选密码套件之前，根据“签名算法”扩展检查它们。这有点不雅观，但它是一种折衷方案，旨在最大限度地减少对原始密码套件设计的更改。
In addition, the hash and signature algorithms MUST be compatible with the key in the server's end-entity certificate. RSA keys MAY be used with any permitted hash algorithm, subject to restrictions in the certificate, if any.
此外，哈希和签名算法必须与服务器的终端实体证书中的密钥兼容。RSA密钥可与任何允许的哈希算法一起使用，但需遵守证书中的限制（如果有）。
Because DSA signatures do not contain any secure indication of hash algorithm, there is a risk of hash substitution if multiple hashes may be used with any key. Currently, DSA [DSS] may only be used with SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use of other digest algorithms with DSA, as well as guidance as to which
由于DSA签名不包含哈希算法的任何安全指示，因此如果对任何密钥使用多个哈希，则存在哈希替换的风险。目前，DSA[DSS]只能与SHA-1一起使用。DSS[DSS-3]的未来修订版预计将允许在DSA中使用其他摘要算法，以及关于哪些算法的指南
digest algorithms should be used with each key size. In addition, future revisions of [PKIX] may specify mechanisms for certificates to indicate which digest algorithms are to be used with DSA.
摘要算法应与每个密钥大小一起使用。此外，[PKIX]的未来版本可能会指定证书的机制，以指示哪些摘要算法将用于DSA。
As additional cipher suites are defined for TLS that include new key exchange algorithms, the server key exchange message will be sent if and only if the certificate type associated with the key exchange algorithm does not provide enough information for the client to exchange a premaster secret.
由于为包含新密钥交换算法的TLS定义了额外的密码套件，当且仅当与密钥交换算法关联的证书类型没有为客户端提供足够的信息以交换主密钥前的密钥时，才会发送服务器密钥交换消息。
When this message will be sent:
将发送此消息的时间：
A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite. This message, if sent, will immediately follow the ServerKeyExchange message (if it is sent; otherwise, this message follows the server's Certificate message).
如果适用于所选密码套件，非匿名服务器可以选择从客户端请求证书。此消息如果发送，将立即跟随ServerKeyExchange消息（如果已发送；否则，此消息跟随服务器的证书消息）。
Structure of this message:
此消息的结构：
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), (255)
} ClientCertificateType;
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20), (255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
certificate_types A list of the types of certificate types that the client may offer.
证书类型客户端可能提供的证书类型列表。
rsa_sign a certificate containing an RSA key dss_sign a certificate containing a DSA key rsa_fixed_dh a certificate containing a static DH key. dss_fixed_dh a certificate containing a static DH key
rsa_签名包含rsa密钥的证书dss_签名包含DSA密钥的证书rsa_固定_dh包含静态dh密钥的证书。dss_fixed_dh包含静态dh密钥的证书
supported_signature_algorithms A list of the hash/signature algorithm pairs that the server is able to verify, listed in descending order of preference.
受支持的\u签名\u算法服务器能够验证的哈希/签名算法对列表，按首选项降序列出。
certificate_authorities A list of the distinguished names [X501] of acceptable certificate_authorities, represented in DER-encoded format. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space. If the certificate_authorities list is empty, then the client MAY send any certificate of the appropriate ClientCertificateType, unless there is some external arrangement to the contrary.
证书颁发机构可接受证书颁发机构的可分辨名称列表[X501]，以DER编码格式表示。这些可分辨名称可以为根CA或从属CA指定所需的可分辨名称；因此，此消息可用于描述已知根以及所需的授权空间。如果证书颁发机构列表为空，则客户机可以发送相应ClientCertificateType的任何证书，除非存在与此相反的外部安排。
The interaction of the certificate_types and supported_signature_algorithms fields is somewhat complicated. certificate_types has been present in TLS since SSLv3, but was somewhat underspecified. Much of its functionality is superseded by supported_signature_algorithms. The following rules apply:
证书类型和支持的签名算法字段之间的交互有些复杂。自SSLv3以来，TLS中就出现了证书类型，但有点不明确。它的许多功能被支持的_签名_算法所取代。以下规则适用：
- Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_algorithms.
- 客户端提供的任何证书都必须使用支持的\u签名\u算法中的哈希/签名算法对进行签名。
- The end-entity certificate provided by the client MUST contain a key that is compatible with certificate_types. If the key is a signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms.
- 客户端提供的最终实体证书必须包含与证书类型兼容的密钥。如果密钥是签名密钥，则它必须可用于支持的\u签名\u算法中的某些哈希/签名算法对。
- For historical reasons, the names of some client certificate types include the algorithm used to sign the certificate. For example, in earlier versions of TLS, rsa_fixed_dh meant a certificate signed with RSA and containing a static DH key. In TLS 1.2, this functionality has been obsoleted by the supported_signature_algorithms, and the certificate type no longer restricts the algorithm used to sign the certificate. For example, if the server sends dss_fixed_dh certificate type and {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply with a certificate containing a static DH key, signed with RSA-SHA1.
- 由于历史原因，某些客户端证书类型的名称包括用于签署证书的算法。例如，在TLS的早期版本中，rsa_fixed_dh表示使用rsa签名并包含静态dh密钥的证书。在TLS 1.2中，此功能已被支持的\u签名\u算法淘汰，证书类型不再限制用于签名证书的算法。例如，如果服务器发送dss_fixed_dh证书类型和{sha1，dsa}，{sha1，rsa}}签名类型，则客户端可能会使用包含静态dh密钥的证书（使用rsa-sha1签名）进行回复。
New ClientCertificateType values are assigned by IANA as described in Section 12.
新的ClientCertificateType值由IANA分配，如第12节所述。
Note: Values listed as RESERVED may not be used. They were used in SSLv3.
注：不得使用列为保留的值。它们在SSLv3中使用。
Note: It is a fatal handshake_failure alert for an anonymous server to request client authentication.
注意：这是匿名服务器请求客户端身份验证的致命握手失败警报。
When this message will be sent:
将发送此消息的时间：
The ServerHelloDone message is sent by the server to indicate the end of the ServerHello and associated messages. After sending this message, the server will wait for a client response.
服务器发送ServerHelloDone消息以指示ServerHello和相关消息的结束。发送此消息后，服务器将等待客户端响应。
Meaning of this message:
此信息的含义：
This message means that the server is done sending messages to support the key exchange, and the client can proceed with its phase of the key exchange.
此消息表示服务器已完成发送消息以支持密钥交换，客户端可以继续其密钥交换阶段。
Upon receipt of the ServerHelloDone message, the client SHOULD verify that the server provided a valid certificate, if required, and check that the server hello parameters are acceptable.
收到ServerHelloDone消息后，客户机应验证服务器是否提供了有效的证书（如果需要），并检查服务器hello参数是否可接受。
Structure of this message:
此消息的结构：
struct { } ServerHelloDone;
struct { } ServerHelloDone;
When this message will be sent:
将发送此消息的时间：
This is the first message the client can send after receiving a ServerHelloDone message. This message is only sent if the server requests a certificate. If no suitable certificate is available, the client MUST send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero. If the client does not send any certificates, the server MAY at its discretion either continue the handshake without client authentication, or respond with a fatal handshake_failure 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 send a fatal alert.
这是客户端在收到ServerHelloDone消息后可以发送的第一条消息。仅当服务器请求证书时，才会发送此消息。如果没有合适的证书可用，客户端必须发送不包含证书的证书消息。也就是说，证书列表结构的长度为零。如果客户端未发送任何证书，服务器可自行决定在没有客户端身份验证的情况下继续握手，或发出致命握手失败警报。此外，如果证书链的某些方面不可接受（例如，它没有由已知的、受信任的CA签名），服务器可以自行决定继续握手（考虑到客户端未经验证）或发送致命警报。
Client certificates are sent using the Certificate structure defined in Section 7.4.2.
使用第7.4.2节中定义的证书结构发送客户端证书。
Meaning of this message:
此信息的含义：
This message conveys the client's certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating the premaster secret (for non-ephemeral Diffie-Hellman). The certificate MUST be appropriate for the negotiated cipher suite's key exchange algorithm, and any negotiated extensions.
此消息将客户端的证书链传送到服务器；服务器将在验证CertificateVerify消息（当客户端身份验证基于签名时）或计算premaster机密（对于非短暂的Diffie-Hellman）时使用它。证书必须适合协商密码套件的密钥交换算法和任何协商扩展。
In particular:
特别地：
- The certificate type MUST be X.509v3, unless explicitly negotiated otherwise (e.g., [TLSPGP]).
- 除非另有明确协商（例如[TLSPGP]），否则证书类型必须为X.509v3。
- The end-entity certificate's public key (and associated restrictions) has to be compatible with the certificate types listed in CertificateRequest:
- 终端实体证书的公钥（和相关限制）必须与CertificateRequest中列出的证书类型兼容：
Client Cert. Type Certificate Key Type
客户端证书类型证书密钥类型
rsa_sign RSA public key; the certificate MUST allow the key to be used for signing with the signature scheme and hash algorithm that will be employed in the certificate verify message.
rsa_签名rsa公钥；证书必须允许密钥用于签名，签名方案和哈希算法将在证书验证消息中使用。
dss_sign DSA public key; the certificate MUST allow the key to be used for signing with the hash algorithm that will be employed in the certificate verify message.
dss_签名DSA公钥；证书必须允许密钥用于使用将在证书验证消息中使用的哈希算法进行签名。
ecdsa_sign ECDSA-capable public key; the certificate MUST allow the key to be used for signing with the hash algorithm that will be employed in the certificate verify message; the public key MUST use a curve and point format supported by the server.
ecdsa_-sign支持ecdsa的公钥；证书必须允许密钥用于使用将在证书验证消息中使用的哈希算法进行签名；公钥必须使用服务器支持的曲线和点格式。
rsa_fixed_dh Diffie-Hellman public key; MUST use the same dss_fixed_dh parameters as server's key.
rsa_固定_dh Diffie-Hellman公钥；必须使用与服务器密钥相同的dss_fixed_dh参数。
rsa_fixed_ecdh ECDH-capable public key; MUST use the ecdsa_fixed_ecdh same curve as the server's key, and MUST use a point format supported by the server.
rsa_固定_ecdh支持ecdh的公钥；必须使用与服务器密钥相同的ecdsa_fixed_ecdh曲线，并且必须使用服务器支持的点格式。
- If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs.
- 如果证书请求消息中的证书颁发机构列表非空，则证书链中的一个证书应由列出的CA之一颁发。
- The certificates MUST be signed using an acceptable hash/ signature algorithm pair, as described in Section 7.4.4. Note that this relaxes the constraints on certificate-signing algorithms found in prior versions of TLS.
- 必须使用可接受的哈希/签名算法对证书进行签名，如第7.4.4节所述。请注意，这放松了TLS早期版本中对证书签名算法的限制。
Note that, as with the server certificate, there are certificates that use algorithms/algorithm combinations that cannot be currently used with TLS.
请注意，与服务器证书一样，有些证书使用当前无法与TLS一起使用的算法/算法组合。
When this message will be sent:
将发送此消息的时间：
This message is always sent by the client. It MUST immediately follow the client certificate message, if it is sent. Otherwise, it MUST be the first message sent by the client after it receives the ServerHelloDone message.
此消息始终由客户端发送。如果发送了客户端证书消息，它必须立即跟随该消息。否则，它必须是客户端收到ServerHelloDone消息后发送的第一条消息。
Meaning of this message:
此信息的含义：
With this message, the premaster secret is set, either by direct transmission of the RSA-encrypted secret or by the transmission of Diffie-Hellman parameters that will allow each side to agree upon the same premaster secret.
通过此消息，可以通过直接传输RSA加密密钥或通过传输Diffie-Hellman参数来设置premaster密钥，这将允许双方同意相同的premaster密钥。
When the client is using an ephemeral Diffie-Hellman exponent, then this message contains the client's Diffie-Hellman public value. If the client is sending a certificate containing a static DH exponent (i.e., it is doing fixed_dh client authentication), then this message MUST be sent but MUST be empty.
当客户端使用短暂的Diffie-Hellman指数时，此消息包含客户端的Diffie-Hellman公共值。如果客户端正在发送包含静态DH指数的证书（即，它正在执行fixed_DH客户端身份验证），则必须发送此消息，但必须为空。
Structure of this message:
此消息的结构：
The choice of messages depends on which key exchange method has been selected. See Section 7.4.3 for the KeyExchangeAlgorithm definition.
消息的选择取决于选择的密钥交换方法。有关KeyExchangeAlgorithm的定义，请参见第7.4.3节。
struct {
select (KeyExchangeAlgorithm) {
case rsa:
EncryptedPreMasterSecret;
case dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case rsa:
EncryptedPreMasterSecret;
case dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
Meaning of this message:
此信息的含义：
If RSA is being used for key agreement and authentication, the client generates a 48-byte premaster secret, encrypts it using the public key from the server's certificate, and sends the result in an encrypted premaster secret message. This structure is a variant of the ClientKeyExchange message and is not a message in itself.
如果RSA用于密钥协商和身份验证，客户端将生成一个48字节的premaster机密，使用服务器证书中的公钥对其进行加密，并将结果发送到加密的premaster机密消息中。此结构是ClientKeyExchange消息的变体，而不是消息本身。
Structure of this message:
此消息的结构：
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
client_version The latest (newest) version supported by the client. This is used to detect version rollback attacks.
客户端版本客户端支持的最新（最新）版本。这用于检测版本回滚攻击。
random 46 securely-generated random bytes.
随机生成的随机字节。
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
pre_master_secret This random value is generated by the client and is used to generate the master secret, as specified in Section 8.1.
pre_master_secret此随机值由客户端生成，用于生成主密钥，如第8.1节所述。
Note: The version number in the PreMasterSecret is the version offered by the client in the ClientHello.client_version, not the version negotiated for the connection. This feature is designed to prevent rollback attacks. Unfortunately, some old implementations use the negotiated version instead, and therefore checking the version number may lead to failure to interoperate with such incorrect client implementations.
注意：PreMasterSecret中的版本号是客户端在ClientHello.client_版本中提供的版本，而不是为连接协商的版本。此功能旨在防止回滚攻击。不幸的是，一些旧的实现使用协商版本，因此检查版本号可能会导致无法与这些不正确的客户端实现进行互操作。
Client implementations MUST always send the correct version number in PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, server implementations MUST check the version number as described in the note below. If the version number is TLS 1.0 or earlier, server implementations SHOULD check the version number, but MAY have a configuration option to disable the check. Note that if the check fails, the PreMasterSecret SHOULD be randomized as described below.
客户端实现必须始终以PreMasterSecret格式发送正确的版本号。如果ClientHello.client_版本为TLS 1.1或更高版本，则服务器实现必须按照下面的说明检查版本号。如果版本号为TLS 1.0或更早，服务器实现应检查版本号，但可能有一个配置选项来禁用检查。请注意，如果检查失败，则应按如下所述随机化PreMasterSecret。
Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. [KPR03] can be used to attack a TLS server that reveals whether a particular message, when decrypted, is properly PKCS#1 formatted, contains a valid PreMasterSecret structure, or has the correct version number.
注意：Bleichenbacher[BLEI]和Klima等人[KPR03]发现的攻击可用于攻击TLS服务器，该服务器显示特定消息在解密时是否正确设置PKCS#1格式、是否包含有效的PreMasterSecret结构或是否具有正确的版本号。
As described by Klima [KPR03], these vulnerabilities can be avoided by treating incorrectly formatted message blocks and/or mismatched version numbers in a manner indistinguishable from correctly formatted RSA blocks. In other words:
如Klima[KPR03]所述，通过以与正确格式的RSA块无法区分的方式处理格式不正确的消息块和/或不匹配的版本号，可以避免这些漏洞。换言之：
1. Generate a string R of 46 random bytes
1. 生成46个随机字节的字符串R
2. Decrypt the message to recover the plaintext M
2. 解密消息以恢复明文M
3. If the PKCS#1 padding is not correct, or the length of message M is not exactly 48 bytes: pre_master_secret = ClientHello.client_version || R else If ClientHello.client_version <= TLS 1.0, and version number check is explicitly disabled: pre_master_secret = M else: pre_master_secret = ClientHello.client_version || M[2..47]
3. 如果PKCS#1填充不正确，或者消息M的长度不完全是48字节：pre_master_secret=ClientHello.client|version | R else如果ClientHello.client_version<=TLS 1.0，并且版本号检查被显式禁用：pre_master_secret=M else:pre_master_secret=ClientHello.ClientHello.client|version | M[2..47]
Note that explicitly constructing the pre_master_secret with the ClientHello.client_version produces an invalid master_secret if the client has sent the wrong version in the original pre_master_secret.
请注意，如果客户端在原始pre_master_secret中发送了错误的版本，则使用ClientHello.client_版本显式构造pre_master_secret会生成无效的master_secret。
An alternative approach is to treat a version number mismatch as a PKCS-1 formatting error and randomize the premaster secret completely:
另一种方法是将版本号不匹配视为PKCS-1格式错误，并将premaster机密完全随机：
1. Generate a string R of 48 random bytes
1. 生成48个随机字节的字符串R
2. Decrypt the message to recover the plaintext M
2. 解密消息以恢复明文M
3. If the PKCS#1 padding is not correct, or the length of message M is not exactly 48 bytes: pre_master_secret = R else If ClientHello.client_version <= TLS 1.0, and version number check is explicitly disabled: premaster secret = M else If M[0..1] != ClientHello.client_version: premaster secret = R else: premaster secret = M
3. 如果PKCS#1填充不正确，或者消息M的长度不完全是48字节：pre_master_secret=R else如果ClientHello.client_version<=TLS 1.0，并且版本号检查被显式禁用：premaster secret=M else如果M[0..1]！=ClientHello.client\u版本：premaster secret=R其他：premaster secret=M
Although no practical attacks against this construction are known, Klima et al. [KPR03] describe some theoretical attacks, and therefore the first construction described is RECOMMENDED.
尽管目前还不知道针对这种结构的实际攻击，但Klima等人[KPR03]描述了一些理论攻击，因此建议使用所描述的第一种结构。
In any case, a TLS server MUST NOT generate an alert if processing an RSA-encrypted premaster secret message fails, or the version number is not as expected. Instead, it MUST continue the handshake with a randomly generated premaster secret. It may be useful to log the real cause of failure for troubleshooting purposes; however, care must be taken to avoid leaking the information to an attacker (through, e.g., timing, log files, or other channels.)
在任何情况下，如果处理RSA加密的premaster机密消息失败，或者版本号不符合预期，TLS服务器都不得生成警报。相反，它必须使用随机生成的premaster秘密继续握手。记录故障的真正原因可能有助于进行故障排除；但是，必须小心避免将信息泄漏给攻击者（例如通过计时、日志文件或其他渠道）
The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure against the Bleichenbacher attack. However, for maximal compatibility with earlier versions of TLS, this specification uses the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known to exist provided that the above recommendations are followed.
[PKCS1]中定义的RSAES-OAEP加密方案对Bleichenbacher攻击更安全。但是，为了最大限度地与TLS的早期版本兼容，本规范使用了RSAES-PKCS1-v1_5方案。如果遵循上述建议，则已知不存在Bleichenbacher攻击的变体。
Implementation note: Public-key-encrypted data is represented as an opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted PreMasterSecret in a ClientKeyExchange is preceded by two length bytes. These bytes are redundant in the case of RSA because the EncryptedPreMasterSecret is the only data in the ClientKeyExchange and its length can therefore be unambiguously determined. The SSLv3 specification was not clear about the encoding of public-key-encrypted data, and therefore many SSLv3 implementations do not include the length bytes -- they encode the RSA-encrypted data directly in the ClientKeyExchange message.
实施说明：公钥加密数据表示为不透明向量<0..2^16-1>（参见第4.7节）。因此，ClientKeyExchange中RSA加密的PreMasterSecret前面有两个长度字节。对于RSA，这些字节是冗余的，因为EncryptedPreMasterSecret是ClientKeyExchange中唯一的数据，因此可以明确地确定其长度。SSLv3规范不清楚公钥加密数据的编码，因此许多SSLv3实现不包括长度字节——它们直接在ClientKeyExchange消息中对RSA加密数据进行编码。
This specification requires correct encoding of the EncryptedPreMasterSecret complete with length bytes. The resulting PDU is incompatible with many SSLv3 implementations. Implementors
此规范要求正确编码EncryptedPreMasterSecret，并包含长度字节。生成的PDU与许多SSLv3实现不兼容。实施者
upgrading from SSLv3 MUST modify their implementations to generate and accept the correct encoding. Implementors who wish to be compatible with both SSLv3 and TLS should make their implementation's behavior dependent on the protocol version.
从SSLv3升级必须修改它们的实现，以生成并接受正确的编码。希望与SSLv3和TLS兼容的实现者应该使其实现的行为依赖于协议版本。
Implementation note: It is now known that remote timing-based attacks on TLS are possible, at least when the client and server are on the same LAN. Accordingly, implementations that use static RSA keys MUST use RSA blinding or some other anti-timing technique, as described in [TIMING].
实施说明：现在已经知道，至少当客户机和服务器位于同一LAN上时，基于TLS的远程定时攻击是可能的。因此，使用静态RSA密钥的实现必须使用RSA致盲或其他一些反计时技术，如[计时]中所述。
Meaning of this message:
此信息的含义：
This structure conveys the client's Diffie-Hellman public value (Yc) if it was not already included in the client's certificate. The encoding used for Yc is determined by the enumerated PublicValueEncoding. This structure is a variant of the client key exchange message, and not a message in itself.
如果客户机证书中尚未包含Diffie-Hellman公共值（Yc），则此结构将传递该客户机的Diffie-Hellman公共值。Yc使用的编码由枚举的PublicValueEncoding确定。此结构是客户端密钥交换消息的变体，而不是消息本身。
Structure of this message:
此消息的结构：
enum { implicit, explicit } PublicValueEncoding;
enum { implicit, explicit } PublicValueEncoding;
implicit If the client has sent a certificate which contains a suitable Diffie-Hellman key (for fixed_dh client authentication), then Yc is implicit and does not need to be sent again. In this case, the client key exchange message will be sent, but it MUST be empty.
隐式如果客户端已发送包含合适Diffie-Hellman密钥的证书（用于fixed_dh客户端身份验证），则Yc是隐式的，无需再次发送。在这种情况下，将发送客户端密钥交换消息，但该消息必须为空。
explicit Yc needs to be sent.
需要发送明确的Yc。
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: opaque dh_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: opaque dh_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
dh_Yc The client's Diffie-Hellman public value (Yc).
dh_Yc客户的Diffie Hellman公共价值（Yc）。
When this message will be sent:
将发送此消息的时间：
This message is used to provide explicit verification of a client certificate. This message is only sent following a client certificate that has signing capability (i.e., all certificates except those containing fixed Diffie-Hellman parameters). When sent, it MUST immediately follow the client key exchange message.
此消息用于提供客户端证书的显式验证。此消息仅在具有签名功能的客户端证书（即除包含固定Diffie-Hellman参数的证书外的所有证书）之后发送。发送时，它必须立即跟随客户端密钥交换消息。
Structure of this message:
此消息的结构：
struct {
digitally-signed struct {
opaque handshake_messages[handshake_messages_length];
}
} CertificateVerify;
struct {
digitally-signed struct {
opaque handshake_messages[handshake_messages_length];
}
} CertificateVerify;
Here handshake_messages refers to all handshake messages sent or received, starting at client hello and up to, but not including, this message, including the type and length fields of the handshake messages. This is the concatenation of all the Handshake structures (as defined in Section 7.4) exchanged thus far. Note that this requires both sides to either buffer the messages or compute running hashes for all potential hash algorithms up to the time of the CertificateVerify computation. Servers can minimize this computation cost by offering a restricted set of digest algorithms in the CertificateRequest message.
这里，握手_消息指发送或接收的所有握手消息，从客户端hello开始，直到但不包括此消息，包括握手消息的类型和长度字段。这是迄今为止交换的所有握手结构（定义见第7.4节）的串联。请注意，这需要双方缓冲消息或计算到CertificateVerify计算时所有潜在哈希算法的运行哈希。服务器可以通过在CertificateRequest消息中提供一组受限的摘要算法来最小化此计算成本。
The hash and signature algorithms used in the signature MUST be one of those present in the supported_signature_algorithms field of the CertificateRequest message. In addition, the hash and signature algorithms MUST be compatible with the key in the client's end-entity certificate. RSA keys MAY be used with any permitted hash algorithm, subject to restrictions in the certificate, if any.
签名中使用的哈希算法和签名算法必须是CertificateRequest消息的supported_signature_algorithms字段中的算法之一。此外，哈希和签名算法必须与客户端的最终实体证书中的密钥兼容。RSA密钥可与任何允许的哈希算法一起使用，但需遵守证书中的限制（如果有）。
Because DSA signatures do not contain any secure indication of hash algorithm, there is a risk of hash substitution if multiple hashes may be used with any key. Currently, DSA [DSS] may only be used with SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use of other digest algorithms with DSA, as well as guidance as to which digest algorithms should be used with each key size. In addition, future revisions of [PKIX] may specify mechanisms for certificates to indicate which digest algorithms are to be used with DSA.
由于DSA签名不包含哈希算法的任何安全指示，因此如果对任何密钥使用多个哈希，则存在哈希替换的风险。目前，DSA[DSS]只能与SHA-1一起使用。DSS[DSS-3]的未来版本预计将允许在DSA中使用其他摘要算法，以及指导每个密钥大小应使用哪些摘要算法。此外，[PKIX]的未来版本可能会指定证书的机制，以指示哪些摘要算法将用于DSA。
When this message will be sent:
将发送此消息的时间：
A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. It is essential that a change cipher spec message be received between the other handshake messages and the Finished message.
完成的消息总是在更改密码规范消息之后立即发送，以验证密钥交换和身份验证过程是否成功。必须在其他握手消息和完成的消息之间接收更改密码规范消息。
Meaning of this message:
此信息的含义：
The Finished message is the first one protected with the just negotiated algorithms, keys, and secrets. Recipients of Finished messages MUST verify that the contents are correct. Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.
完成的消息是第一个使用刚刚协商的算法、密钥和机密进行保护的消息。完成邮件的收件人必须验证内容是否正确。一旦一方发送了完成的消息并从其对等方接收并验证了完成的消息，它就可以开始通过连接发送和接收应用程序数据。
Structure of this message:
此消息的结构：
struct {
opaque verify_data[verify_data_length];
} Finished;
struct {
opaque verify_data[verify_data_length];
} Finished;
verify_data PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1];
验证数据PRF（主密钥、完成的标签、散列（握手消息））[0..验证数据长度-1]；
finished_label For Finished messages sent by the client, the string "client finished". For Finished messages sent by the server, the string "server finished".
finished\由客户端发送的已完成消息的标签，字符串“client finished”。对于服务器发送的已完成消息，字符串“server Finished”。
Hash denotes a Hash of the handshake messages. For the PRF defined in Section 5, the Hash MUST be the Hash used as the basis for the PRF. Any cipher suite which defines a different PRF MUST also define the Hash to use in the Finished computation.
哈希表示握手消息的哈希。对于第5节中定义的PRF，哈希必须是用作PRF基础的哈希。任何定义不同PRF的密码套件也必须定义要在完成的计算中使用的哈希。
In previous versions of TLS, the verify_data was always 12 octets long. In the current version of TLS, it depends on the cipher suite. Any cipher suite which does not explicitly specify verify_data_length has a verify_data_length equal to 12. This includes all existing cipher suites. Note that this representation has the same encoding as with previous versions. Future cipher suites MAY specify other lengths but such length MUST be at least 12 bytes.
在以前版本的TLS中，验证_数据的长度始终为12个八位字节。在TLS的当前版本中，它取决于密码套件。任何未明确指定verify_data_长度的密码套件的verify_data_长度都等于12。这包括所有现有的密码套件。请注意，此表示与以前的版本具有相同的编码。未来的密码套件可能会指定其他长度，但该长度必须至少为12字节。
handshake_messages All of the data from all messages in this handshake (not including any HelloRequest messages) up to, but not including, this message. This is only data visible at the handshake layer and does not include record layer headers. This is the concatenation of all the Handshake structures as defined in Section 7.4, exchanged thus far.
握手\此握手中所有消息（不包括任何HelloRequest消息）中的所有数据，直到但不包括此消息。这是握手层上唯一可见的数据，不包括记录层标题。这是迄今为止交换的第7.4节中定义的所有握手结构的串联。
It is a fatal error if a Finished message is not preceded by a ChangeCipherSpec message at the appropriate point in the handshake.
如果在握手的适当位置，完成的消息前面没有ChangeCipherSpec消息，则这是一个致命错误。
The value handshake_messages includes all handshake messages starting at ClientHello up to, but not including, this Finished message. This may be different from handshake_messages in Section 7.4.8 because it would include the CertificateVerify message (if sent). Also, the handshake_messages for the Finished message sent by the client will be different from that for the Finished message sent by the server, because the one that is sent second will include the prior one.
值handshake_messages包括从ClientHello开始直到（但不包括）此完成消息的所有握手消息。这可能不同于第7.4.8节中的握手消息，因为它将包括CertificateVerify消息（如果已发送）。此外，客户端发送的已完成消息的握手_消息将与服务器发送的已完成消息的握手_消息不同，因为第二次发送的握手_消息将包括前一次。
Note: ChangeCipherSpec messages, alerts, and any other record types are not handshake messages and are not included in the hash computations. Also, HelloRequest messages are omitted from handshake hashes.
注意：ChangeCipherSpec消息、警报和任何其他记录类型不是握手消息，也不包括在哈希计算中。此外，HelloRequest消息从握手哈希中省略。
In order to begin connection protection, the TLS Record Protocol requires specification of a suite of algorithms, a master secret, and the client and server random values. The authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the server and revealed in the ServerHello message. The compression algorithm is negotiated in the hello messages, and the random values are exchanged in the hello messages. All that remains is to calculate the master secret.
为了开始连接保护，TLS记录协议需要指定一套算法、主密钥以及客户端和服务器随机值。身份验证、加密和MAC算法由服务器选择并在ServerHello消息中显示的密码套件决定。压缩算法在hello消息中协商，随机值在hello消息中交换。剩下的就是计算主秘密。
For all key exchange methods, the same algorithm is used to convert the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed.
对于所有密钥交换方法，使用相同的算法将pre_master_秘密转换为master_秘密。在计算主密钥后，应从内存中删除预主密钥。
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
master_secret=PRF（pre_master_secret，“master secret”，ClientHello.random+ServerHello.random）[0..47]；
The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary depending on key exchange method.
主密钥的长度始终恰好为48字节。根据密钥交换方法，premaster密钥的长度会有所不同。
When RSA is used for server authentication and key exchange, a 48- byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret, as specified above.
当RSA用于服务器身份验证和密钥交换时，客户端会生成一个48字节的pre_master_密钥，并在服务器的公钥下进行加密，然后发送到服务器。服务器使用其私钥解密pre_master_机密。然后，双方将pre_master_secret转换为master_secret，如上所述。
A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret.
执行常规的Diffie-Hellman计算。协商密钥（Z）用作pre_master_secret，并转换为master_secret，如上所述。包含所有零位的Z的前导字节在用作pre_master_secret之前被剥离。
Note: Diffie-Hellman parameters are specified by the server and may be either ephemeral or contained within the server's certificate.
注意：Diffie-Hellman参数由服务器指定，可以是短暂的，也可以包含在服务器的证书中。
In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).
在没有应用程序配置文件标准另有规定的情况下，符合TLS的应用程序必须使用_AES_128_CBC_SHA实现密码套件TLS_RSA_（定义见附录a.5）。
Application data messages are carried by the record layer and are fragmented, compressed, and encrypted based on the current connection state. The messages are treated as transparent data to the record layer.
应用程序数据消息由记录层承载，并根据当前连接状态进行分段、压缩和加密。消息被视为对记录层透明的数据。
Security issues are discussed throughout this memo, especially in Appendices D, E, and F.
本备忘录中讨论了安全问题，尤其是附录D、E和F。
This document uses several registries that were originally created in [TLS1.1]. IANA has updated these to reference this document. The registries and their allocation policies (unchanged from [TLS1.1]) are listed below.
本文档使用了几个最初在[TLS1.1]中创建的注册表。IANA已更新这些文件以参考本文件。以下列出了注册中心及其分配策略（与[TLS1.1]相同）。
- TLS ClientCertificateType Identifiers Registry: Future values in the range 0-63 (decimal) inclusive are assigned via Standards Action [RFC2434]. Values in the range 64-223 (decimal) inclusive are assigned via Specification Required [RFC2434]. Values from 224-255 (decimal) inclusive are reserved for Private Use [RFC2434].
- TLS ClientCertificateType标识符注册表：0-63（十进制）范围内的未来值通过标准操作[RFC2434]分配。64-223（十进制）范围内的值通过所需规范[RFC2434]分配。224-255（十进制）之间的值保留供私人使用[RFC2434]。
- TLS Cipher Suite Registry: Future values with the first byte in the range 0-191 (decimal) inclusive are assigned via Standards Action [RFC2434]. Values with the first byte in the range 192-254 (decimal) are assigned via Specification Required [RFC2434]. Values with the first byte 255 (decimal) are reserved for Private Use [RFC2434].
- TLS Cipher Suite注册表：第一个字节在0-191（十进制）范围内的未来值通过标准操作[RFC2434]分配。第一个字节在192-254（十进制）范围内的值通过所需规范[RFC2434]分配。第一个字节为255（十进制）的值保留供私人使用[RFC2434]。
- This document defines several new HMAC-SHA256-based cipher suites, whose values (in Appendix A.5) have been allocated from the TLS Cipher Suite registry.
- 本文件定义了几个新的基于HMAC-SHA256的密码套件，其值（见附录A.5）已从TLS密码套件注册表中分配。
- TLS ContentType Registry: Future values are allocated via Standards Action [RFC2434].
- TLS ContentType注册表：未来的值通过标准操作[RFC2434]分配。
- TLS Alert Registry: Future values are allocated via Standards Action [RFC2434].
- TLS警报注册表：通过标准操作[RFC2434]分配未来值。
- TLS HandshakeType Registry: Future values are allocated via Standards Action [RFC2434].
- TLS握手类型注册表：未来的值通过标准操作[RFC2434]分配。
This document also uses a registry originally created in [RFC4366]. IANA has updated it to reference this document. The registry and its allocation policy (unchanged from [RFC4366]) is listed below:
本文档还使用最初在[RFC4366]中创建的注册表。IANA已将其更新为参考本文件。注册表及其分配策略（与[RFC4366]相同）如下所示：
- TLS ExtensionType Registry: Future values are allocated via IETF Consensus [RFC2434]. IANA has updated this registry to include the signature_algorithms extension and its corresponding value (see Section 7.4.1.4).
- TLS ExtensionType注册表：未来的值通过IETF共识[RFC2434]分配。IANA已更新此注册表，以包括签名算法扩展及其相应值（见第7.4.1.4节）。
In addition, this document defines two new registries to be maintained by IANA:
此外，本文件定义了IANA将维护的两个新登记册：
- TLS SignatureAlgorithm Registry: The registry has been initially populated with the values described in Section 7.4.1.4.1. Future values in the range 0-63 (decimal) inclusive are assigned via Standards Action [RFC2434]. Values in the range 64-223 (decimal) inclusive are assigned via Specification Required [RFC2434]. Values from 224-255 (decimal) inclusive are reserved for Private Use [RFC2434].
- TLS SignatureAlgorithm注册表：注册表最初使用第7.4.1.4.1节中描述的值填充。0-63（十进制）范围内的未来值通过标准行动[RFC2434]分配。64-223（十进制）范围内的值通过所需规范[RFC2434]分配。224-255（十进制）之间的值保留供私人使用[RFC2434]。
- TLS HashAlgorithm Registry: The registry has been initially populated with the values described in Section 7.4.1.4.1. Future values in the range 0-63 (decimal) inclusive are assigned via Standards Action [RFC2434]. Values in the range 64-223 (decimal) inclusive are assigned via Specification Required [RFC2434]. Values from 224-255 (decimal) inclusive are reserved for Private Use [RFC2434].
- TLS HashAlgorithm注册表：注册表最初使用第7.4.1.4.1节中描述的值填充。0-63（十进制）范围内的未来值通过标准行动[RFC2434]分配。64-223（十进制）范围内的值通过所需规范[RFC2434]分配。224-255（十进制）之间的值保留供私人使用[RFC2434]。
This document also uses the TLS Compression Method Identifiers Registry, defined in [RFC3749]. IANA has allocated value 0 for the "null" compression method.
本文档还使用了[RFC3749]中定义的TLS压缩方法标识符注册表。IANA为“null”压缩方法分配了值0。
This section describes protocol types and constants.
本节介绍协议类型和常量。
struct {
uint8 major;
uint8 minor;
} ProtocolVersion;
struct {
uint8 major;
uint8 minor;
} ProtocolVersion;
ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (SecurityParameters.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
case aead: GenericAEADCipher;
} fragment;
} TLSCiphertext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (SecurityParameters.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
case aead: GenericAEADCipher;
} fragment;
} TLSCiphertext;
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher;
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
} GenericStreamCipher;
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
struct {
opaque IV[SecurityParameters.record_iv_length];
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
};
} GenericBlockCipher;
struct {
opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct {
opaque content[TLSCompressed.length];
};
} GenericAEADCipher;
struct {
opaque nonce_explicit[SecurityParameters.record_iv_length];
aead-ciphered struct {
opaque content[TLSCompressed.length];
};
} GenericAEADCipher;
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
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(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),
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(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),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
(255)
} AlertDescription;
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20)
(255)
} HandshakeType;
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20)
(255)
} HandshakeType;
struct {
HandshakeType msg_type;
uint24 length;
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
struct {
HandshakeType msg_type;
uint24 length;
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
struct { } HelloRequest;
struct { } HelloRequest;
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
opaque SessionID<0..32>;
opaque SessionID<0..32>;
uint8 CipherSuite[2];
uint8密码套件[2]；
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..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 {
signature_algorithms(13), (65535)
} ExtensionType;
enum {
signature_algorithms(13), (65535)
} ExtensionType;
enum{
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
enum {
anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
} SignatureAlgorithm;
enum{
none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
sha512(6), (255)
} HashAlgorithm;
enum {
anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
} SignatureAlgorithm;
struct {
HashAlgorithm hash;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
struct {
HashAlgorithm hash;
SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-1>;
SignatureAndHashAlgorithm
supported_signature_algorithms<2..2^16-1>;
opaque ASN.1Cert<2^24-1>;
opaque ASN.1Cert<2^24-1>;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} KeyExchangeAlgorithm;
enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} KeyExchangeAlgorithm;
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
case rsa:
case dh_dss:
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
case rsa:
case dh_dss:
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} ServerKeyExchange;
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
} ClientCertificateType;
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct { } ServerHelloDone;
struct { } ServerHelloDone;
struct {
select (KeyExchangeAlgorithm) {
case rsa:
EncryptedPreMasterSecret;
case dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case rsa:
EncryptedPreMasterSecret;
case dhe_dss:
case dhe_rsa:
case dh_dss:
case dh_rsa:
case dh_anon:
ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
enum { implicit, explicit } PublicValueEncoding;
enum { implicit, explicit } PublicValueEncoding;
struct {
select (PublicValueEncoding) {
case implicit: struct {};
case explicit: opaque DH_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
struct {
select (PublicValueEncoding) {
case implicit: struct {};
case explicit: opaque DH_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
struct {
digitally-signed struct {
opaque handshake_messages[handshake_messages_length];
}
} CertificateVerify;
struct {
digitally-signed struct {
opaque handshake_messages[handshake_messages_length];
}
} CertificateVerify;
struct {
opaque verify_data[verify_data_length];
} Finished;
struct {
opaque verify_data[verify_data_length];
} Finished;
The following values define the cipher suite codes used in the ClientHello and ServerHello messages.
以下值定义ClientHello和ServerHello消息中使用的密码套件代码。
A cipher suite defines a cipher specification supported in TLS Version 1.2.
密码套件定义TLS版本1.2中支持的密码规范。
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS connection during the first handshake on that channel, but MUST NOT be negotiated, as it provides no more protection than an unsecured connection.
指定了TLS_NULL_WITH_NULL_NULL，是该通道上第一次握手期间TLS连接的初始状态，但不得协商，因为它提供的保护不比不安全的连接多。
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
The following CipherSuite definitions require that the server provide an RSA certificate that can be used for key exchange. The server may request any signature-capable certificate in the certificate request message.
以下密码套件定义要求服务器提供可用于密钥交换的RSA证书。服务器可以在证书请求消息中请求任何具有签名能力的证书。
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D };
The following cipher suite definitions are used for server-authenticated (and optionally client-authenticated) Diffie-Hellman. DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman parameters are signed by a signature-capable certificate, which has been signed by the CA. The signing algorithm used by the server is specified after the DHE component of the CipherSuite name. The server can request any signature-capable certificate from the client for client authentication, or it may request a Diffie-Hellman certificate. Any Diffie-Hellman certificate provided by the client must use the parameters (group and generator) described by the server.
以下密码套件定义用于服务器身份验证（以及可选的客户端身份验证）Diffie Hellman。DH表示密码套件，其中服务器的证书包含由证书颁发机构（CA）签名的Diffie-Hellman参数。DHE表示短暂的Diffie-Hellman，其中Diffie-Hellman参数由CA签署的具有签名能力的证书签名。服务器使用的签名算法在CipherSuite名称的DHE组件之后指定。服务器可以从客户端请求任何支持签名的证书以进行客户端身份验证，也可以请求Diffie-Hellman证书。客户端提供的任何Diffie-Hellman证书都必须使用服务器描述的参数（组和生成器）。
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B };
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B };
The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks. Using this mode therefore is of limited use: These cipher suites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication.)
以下密码套件用于完全匿名的Diffie-Hellman通信，其中任何一方都没有经过身份验证。请注意，此模式易受中间人攻击。因此，使用此模式的用途有限：除非应用层明确要求允许匿名密钥交换，否则TLS 1.2实现不得使用这些密码套件。（匿名密钥交换有时是可以接受的，例如，当没有身份验证设置时，或者当TLS被用作具有其他方式来确保身份验证的更复杂的安全协议的一部分时，支持机会主义加密。）
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D };
Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. While non-anonymous key exchange will generally involve a higher computational and communicational cost than anonymous key exchange, it may be in the interest of interoperability not to disable non-anonymous key exchange when the application layer is allowing anonymous key exchange.
请注意，在不实际验证密钥交换的情况下使用非匿名密钥交换本质上等同于匿名密钥交换，并且适用相同的预防措施。虽然非匿名密钥交换通常比匿名密钥交换涉及更高的计算和通信成本，但在应用层允许匿名密钥交换时，不禁用非匿名密钥交换可能有利于互操作性。
New cipher suite values have been assigned by IANA as described in Section 12.
如第12节所述，IANA分配了新的密码套件值。
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are reserved to avoid collision with Fortezza-based cipher suites in SSL 3.
注意：保留密码套件值{0x00，0x1C}和{0x00，0x1D}，以避免与SSL 3中基于Fortezza的密码套件发生冲突。
These security parameters are determined by the TLS Handshake Protocol and provided as parameters to the TLS record layer in order to initialize a connection state. SecurityParameters includes:
这些安全参数由TLS握手协议确定，并作为参数提供给TLS记录层，以便初始化连接状态。安全参数包括：
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd;
enum { server, client } ConnectionEnd;
enum { tls_prf_sha256 } PRFAlgorithm;
enum { tls_prf_sha256 } PRFAlgorithm;
enum { null, rc4, 3des, aes } BulkCipherAlgorithm;
enum { null, rc4, 3des, aes } BulkCipherAlgorithm;
enum { stream, block, aead } CipherType;
enum { stream, block, aead } CipherType;
enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384,
hmac_sha512} MACAlgorithm;
enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384,
hmac_sha512} MACAlgorithm;
/* Other values may be added to the algorithms specified in
CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm, and
MACAlgorithm. */
/* Other values may be added to the algorithms specified in
CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm, and
MACAlgorithm. */
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct {
ConnectionEnd entity;
PRFAlgorithm prf_algorithm;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 fixed_iv_length;
uint8 record_iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This document changes some of the structures used in that document. This section details the required changes for implementors of both RFC 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing RFC 4492 do not need to read this section.
RFC4492[TLSECC]将椭圆曲线密码套件添加到TLS中。本文档更改了该文档中使用的一些结构。本节详细说明了RFC 4492和TLS 1.2实施者所需的更改。未实现RFC 4492的TLS 1.2实现者无需阅读本节。
This document adds a "signature_algorithm" field to the digitally-signed element in order to identify the signature and digest algorithms used to create a signature. This change applies to digital signatures formed using ECDSA as well, thus allowing ECDSA signatures to be used with digest algorithms other than SHA-1, provided such use is compatible with the certificate and any restrictions imposed by future revisions of [PKIX].
本文档向数字签名元素添加一个“signature_algorithm”（签名算法）字段，以标识用于创建签名的签名和摘要算法。此更改也适用于使用ECDSA形成的数字签名，因此允许ECDSA签名与SHA-1以外的摘要算法一起使用，前提是此类使用与证书和[PKIX]未来版本施加的任何限制兼容。
As described in Sections 7.4.2 and 7.4.6, the restrictions on the signature algorithms used to sign certificates are no longer tied to the cipher suite (when used by the server) or the ClientCertificateType (when used by the client). Thus, the restrictions on the algorithm used to sign certificates specified in Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, the restrictions on the keys in the end-entity certificate remain.
如第7.4.2节和第7.4.6节所述，对用于签署证书的签名算法的限制不再绑定到密码套件（当服务器使用时）或ClientCertificateType（当客户端使用时）。因此，RFC 4492第2节和第3节中规定的对用于签署证书的算法的限制也被放宽。与本文档一样，对最终实体证书中密钥的限制仍然存在。
Advanced Encryption Standard (AES) AES [AES] is a widely used symmetric encryption algorithm. AES is a block cipher with a 128-, 192-, or 256-bit keys and a 16-byte block size. TLS currently only supports the 128- and 256-bit key sizes.
高级加密标准（AES）AES[AES]是一种广泛使用的对称加密算法。AES是一种具有128、192或256位密钥和16字节块大小的分组密码。TLS目前仅支持128位和256位密钥大小。
application protocol An application protocol is a protocol that normally layers directly on top of the transport layer (e.g., TCP/IP). Examples include HTTP, TELNET, FTP, and SMTP.
应用协议应用协议是一种通常直接在传输层（如TCP/IP）之上分层的协议。示例包括HTTP、TELNET、FTP和SMTP。
asymmetric cipher See public key cryptography.
非对称密码参见公钥密码术。
authenticated encryption with additional data (AEAD) A symmetric encryption algorithm that simultaneously provides confidentiality and message integrity.
附加数据认证加密（AEAD）一种对称加密算法，可同时提供机密性和消息完整性。
authentication Authentication is the ability of one entity to determine the identity of another entity.
身份验证是一个实体确定另一个实体身份的能力。
block cipher A block cipher is an algorithm that operates on plaintext in groups of bits, called blocks. 64 bits was, and 128 bits is, a common block size.
分组密码分组密码是一种以位为单位对明文进行运算的算法，称为块。64位和128位是一个公共块大小。
bulk cipher A symmetric encryption algorithm used to encrypt large quantities of data.
批量密码用于加密大量数据的对称加密算法。
cipher block chaining (CBC) CBC is a mode in which every plaintext block encrypted with a block cipher is first exclusive-ORed with the previous ciphertext block (or, in the case of the first block, with the initialization vector). For decryption, every block is first decrypted, then exclusive-ORed with the previous ciphertext block (or IV).
密码块链接（CBC）CBC是一种模式，其中使用块密码加密的每个明文块首先与前一个密文块（或者，在第一个块的情况下，与初始化向量）进行异或运算。对于解密，首先对每个块进行解密，然后与前一个密文块（或IV）进行异或运算。
certificate As part of the X.509 protocol (a.k.a. ISO Authentication framework), certificates are assigned by a trusted Certificate Authority and provide a strong binding between a party's identity or some other attributes and its public key.
证书作为X.509协议（又称ISO认证框架）的一部分，证书由受信任的证书颁发机构分配，并在一方的身份或某些其他属性与其公钥之间提供强绑定。
client The application entity that initiates a TLS connection to a server. This may or may not imply that the client initiated the underlying transport connection. The primary operational difference between the server and client is that the server is generally authenticated, while the client is only optionally authenticated.
客户端启动到服务器的TLS连接的应用程序实体。这可能意味着客户机启动了底层传输连接，也可能不是。服务器和客户机之间的主要操作区别在于，服务器通常经过身份验证，而客户机只是选择性地经过身份验证。
client write key The key used to encrypt data written by the client.
客户端写入密钥用于加密客户端写入的数据的密钥。
client write MAC key The secret data used to authenticate data written by the client.
客户端写入MAC密钥用于验证客户端写入的数据的机密数据。
connection A connection is a transport (in the OSI layering model definition) that provides a suitable type of service. For TLS, such connections are peer-to-peer relationships. The connections are transient. Every connection is associated with one session.
连接连接是（在OSI分层模型定义中）提供适当类型服务的传输。对于TLS，这种连接是对等关系。连接是暂时的。每个连接都与一个会话相关联。
Data Encryption Standard DES [DES] still is a very widely used symmetric encryption algorithm although it is considered as rather weak now. DES is a block cipher with a 56-bit key and an 8-byte block size. Note that in TLS, for key generation purposes, DES is treated as having an 8-byte key length (64 bits), but it still only provides 56 bits
数据加密标准DES[DES]仍然是一种非常广泛使用的对称加密算法，尽管它现在被认为相当弱。DES是一种具有56位密钥和8字节块大小的分组密码。请注意，在TLS中，出于密钥生成目的，DES被视为具有8字节密钥长度（64位），但它仍然只提供56位
of protection. (The low bit of each key byte is presumed to be set to produce odd parity in that key byte.) DES can also be operated in a mode [3DES] where three independent keys and three encryptions are used for each block of data; this uses 168 bits of key (24 bytes in the TLS key generation method) and provides the equivalent of 112 bits of security.
需要保护。（假定每个密钥字节的低位被设置为在该密钥字节中产生奇偶校验。）DES也可以在模式[3DES]下操作，其中每个数据块使用三个独立密钥和三个加密；这使用168位密钥（在TLS密钥生成方法中为24字节），并提供相当于112位的安全性。
Digital Signature Standard (DSS) A standard for digital signing, including the Digital Signing Algorithm, approved by the National Institute of Standards and Technology, defined in NIST FIPS PUB 186-2, "Digital Signature Standard", published January 2000 by the U.S. Department of Commerce [DSS]. A significant update [DSS-3] has been drafted and was published in March 2006.
数字签名标准（DSS）：美国国家标准与技术研究所批准的数字签名标准，包括数字签名算法，由美国商务部[DSS]于2000年1月发布的NIST FIPS PUB 186-2“数字签名标准”中定义。已经起草了一份重要的更新[DSS-3]，并于2006年3月发布。
digital signatures Digital signatures utilize public key cryptography and one-way hash functions to produce a signature of the data that can be authenticated, and is difficult to forge or repudiate.
数字签名数字签名利用公钥密码和单向散列函数生成数据签名，该数据签名可通过身份验证，且难以伪造或否认。
handshake An initial negotiation between client and server that establishes the parameters of their transactions.
握手客户端和服务器之间建立其事务参数的初始协商。
Initialization Vector (IV) When a block cipher is used in CBC mode, the initialization vector is exclusive-ORed with the first plaintext block prior to encryption.
初始化向量（IV）当分组密码在CBC模式下使用时，初始化向量在加密之前与第一个明文块进行异或运算。
Message Authentication Code (MAC) A Message Authentication Code is a one-way hash computed from a message and some secret data. It is difficult to forge without knowing the secret data. Its purpose is to detect if the message has been altered.
消息身份验证码（MAC）消息身份验证码是根据消息和某些机密数据计算的单向散列。不知道秘密数据就很难伪造。其目的是检测消息是否已被更改。
master secret Secure secret data used for generating encryption keys, MAC secrets, and IVs.
主机密用于生成加密密钥、MAC机密和IVs的安全机密数据。
MD5 MD5 [MD5] is a hashing function that converts an arbitrarily long data stream into a hash of fixed size (16 bytes). Due to significant progress in cryptanalysis, at the time of publication of this document, MD5 no longer can be considered a 'secure' hashing function.
MD5 MD5[MD5]是一个散列函数，它将任意长的数据流转换为固定大小（16字节）的散列。由于密码分析的重大进展，在本文档发布时，MD5不再被视为“安全”哈希函数。
public key cryptography A class of cryptographic techniques employing two-key ciphers. Messages encrypted with the public key can only be decrypted with the associated private key. Conversely, messages signed with the private key can be verified with the public key.
公钥密码术采用两种密钥密码的一类密码技术。使用公钥加密的消息只能使用关联的私钥解密。相反，使用私钥签名的消息可以使用公钥进行验证。
one-way hash function A one-way transformation that converts an arbitrary amount of data into a fixed-length hash. It is computationally hard to reverse the transformation or to find collisions. MD5 and SHA are examples of one-way hash functions.
单向散列函数将任意数量的数据转换为固定长度散列的单向转换。在计算上很难反转变换或找到碰撞。MD5和SHA是单向散列函数的示例。
RC4 A stream cipher invented by Ron Rivest. A compatible cipher is described in [SCH].
RC4是罗恩·里维斯特发明的一种流密码。[SCH]中描述了兼容密码。
RSA A very widely used public key algorithm that can be used for either encryption or digital signing. [RSA]
RSA是一种广泛使用的公钥算法，可用于加密或数字签名。[RSA]
server The server is the application entity that responds to requests for connections from clients. See also "client".
服务器服务器是响应客户端连接请求的应用程序实体。另见“客户”。
session A TLS session is an association between a client and a server. Sessions are created by the handshake protocol. Sessions define a set of cryptographic security parameters that can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.
会话TLS会话是客户端和服务器之间的关联。会话是通过握手协议创建的。会话定义了一组可在多个连接之间共享的加密安全参数。会话用于避免为每个连接协商昂贵的新安全参数。
session identifier A session identifier is a value generated by a server that identifies a particular session.
会话标识符会话标识符是由服务器生成的用于标识特定会话的值。
server write key The key used to encrypt data written by the server.
服务器写入密钥用于加密服务器写入的数据的密钥。
server write MAC key The secret data used to authenticate data written by the server.
服务器写入MAC密钥用于验证服务器写入的数据的机密数据。
SHA The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It produces a 20-byte output. Note that all references to SHA (without a numerical suffix) actually use the modified SHA-1 algorithm.
SHA安全哈希算法[SHS]在FIPS PUB 180-2中定义。它产生一个20字节的输出。请注意，所有对SHA的引用（不带数字后缀）实际上都使用修改后的SHA-1算法。
SHA-256 The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It produces a 32-byte output.
SHA-256 256位安全哈希算法在FIPS PUB 180-2中定义。它产生一个32字节的输出。
SSL Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on SSL Version 3.0.
SSL Netscape的安全套接字层协议[SSL3]。TLS基于SSL版本3.0。
stream cipher An encryption algorithm that converts a key into a cryptographically strong keystream, which is then exclusive-ORed with the plaintext.
流密码一种加密算法，将密钥转换为加密强密钥流，然后与明文进行异或运算。
symmetric cipher See bulk cipher.
对称密码参见批量密码。
Transport Layer Security (TLS) This protocol; also, the Transport Layer Security working group of the Internet Engineering Task Force (IETF). See "Working Group Information" at the end of this document (see page 99).
传输层安全（TLS）协议；此外，互联网工程任务组（IETF）的传输层安全工作组。见本文件末尾的“工作组信息”（见第99页）。
Cipher Suite Key Cipher Mac Exchange
密码套件密钥密码Mac交换
TLS_NULL_WITH_NULL_NULL NULL NULL NULL TLS_RSA_WITH_NULL_MD5 RSA NULL MD5 TLS_RSA_WITH_NULL_SHA RSA NULL SHA TLS_RSA_WITH_NULL_SHA256 RSA NULL SHA256 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS AES_128_CBC SHA256 TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256 TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256 TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256 TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
我们的研究结果是一个十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十十我们的研究结果是RSA（RSA）的一个加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密与CBC一起使用DSS 3个EDE和CBC SHA一个加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密U 128_CBC SHA TLS_DHE_DSS_与_AES_128_CBC SHA DHE_DSS AES_128_CBC SHA我们的研究结果是一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，_CBC SHA TLS_DHE_RSA_与_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA一个数字是一个数字，一个数字是一个数字，一个数字是一个数字，一个数字是一个数字，一个数字是一个数字，一个数字是一个数字，一个数字是一个数字，一个数字是一个数字，一个数字是一个数字，一个数字是一个数字，一个数字是一个数字是一个数字，一个数字是一个数字是一个数字，一个数字，一个数字，一个数字是128，一个数字是128，一个数字是128，一个数字是，一个数字，一个数字是一个数字，一个数字，一个数字是一个数字，一个数字是一个数字，一个数字，一个数字，一个数字是一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个数字，一个RSA AES 128 CBC SHA256 TLS DH anon带AES 128 CBC SHA256 DH anon（教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教教U 256_CBC_SHA256 DH_anon AES_256_CBC SHA256
Key IV Block
Cipher Type Material Size Size
------------ ------ -------- ---- -----
NULL Stream 0 0 N/A
RC4_128 Stream 16 0 N/A
3DES_EDE_CBC Block 24 8 8
AES_128_CBC Block 16 16 16
AES_256_CBC Block 32 16 16
Key IV Block
Cipher Type Material Size Size
------------ ------ -------- ---- -----
NULL Stream 0 0 N/A
RC4_128 Stream 16 0 N/A
3DES_EDE_CBC Block 24 8 8
AES_128_CBC Block 16 16 16
AES_256_CBC Block 32 16 16
MAC Algorithm mac_length mac_key_length
-------- ----------- ---------- --------------
NULL N/A 0 0
MD5 HMAC-MD5 16 16
SHA HMAC-SHA1 20 20
SHA256 HMAC-SHA256 32 32
MAC Algorithm mac_length mac_key_length
-------- ----------- ---------- --------------
NULL N/A 0 0
MD5 HMAC-MD5 16 16
SHA HMAC-SHA1 20 20
SHA256 HMAC-SHA256 32 32
Type Indicates whether this is a stream cipher or a block cipher running in CBC mode.
类型指示这是以CBC模式运行的流密码还是分组密码。
Key Material The number of bytes from the key_block that are used for generating the write keys.
Key Material键块中用于生成写入键的字节数。
IV Size The amount of data needed to be generated for the initialization vector. Zero for stream ciphers; equal to the block size for block ciphers (this is equal to SecurityParameters.record_iv_length).
IV Size初始化向量需要生成的数据量。流密码为零；等于分组密码的块大小（这等于SecurityParameters.record_iv_length）。
Block Size The amount of data a block cipher enciphers in one chunk; a block cipher running in CBC mode can only encrypt an even multiple of its block size.
块大小块密码在一个块中加密的数据量；在CBC模式下运行的分组密码只能加密其块大小的偶数倍。
The TLS protocol cannot prevent many common security mistakes. This section provides several recommendations to assist implementors.
TLS协议无法防止许多常见的安全错误。本节提供了一些帮助实施者的建议。
TLS requires a cryptographically secure pseudorandom number generator (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs based on secure hash operations, most notably SHA-1, are acceptable, but cannot provide more security than the size of the random number generator state.
TLS需要加密安全的伪随机数生成器（PRNG）。在设计和播种PRNG时必须小心。基于安全散列操作（尤其是SHA-1）的PRNG是可以接受的，但不能提供比随机数生成器状态更大的安全性。
To estimate the amount of seed material being produced, add the number of bits of unpredictable information in each seed byte. For example, keystroke timing values taken from a PC compatible's 18.2 Hz timer provide 1 or 2 secure bits each, even though the total size of the counter value is 16 bits or more. Seeding a 128-bit PRNG would thus require approximately 100 such timer values.
要估计正在生成的种子材料的数量，请在每个种子字节中添加不可预测信息的位数。例如，即使计数器值的总大小为16位或更多，从PC兼容的18.2 Hz定时器获取的击键定时值也会提供1或2个安全位。因此，播种128位PRNG将需要大约100个这样的计时器值。
[RANDOM] provides guidance on the generation of random values.
[随机]提供生成随机值的指导。
Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Certificates should always be verified to ensure proper signing by a trusted Certificate Authority (CA). The selection and addition of trusted CAs should be done very carefully. Users should be able to view information about the certificate and root CA.
实现负责验证证书的完整性，通常应支持证书撤销消息。应始终验证证书，以确保由受信任的证书颁发机构（CA）正确签名。应非常小心地选择和添加受信任的CA。用户应该能够查看有关证书和根CA的信息。
TLS supports a range of key sizes and security levels, including some that provide no or minimal security. A proper implementation will probably not support many cipher suites. For instance, anonymous Diffie-Hellman is strongly discouraged because it cannot prevent man-in-the-middle attacks. Applications should also enforce minimum and maximum key sizes. For example, certificate chains containing 512- bit RSA keys or signatures are not appropriate for high-security applications.
TLS支持一系列密钥大小和安全级别，包括一些不提供安全性或最低安全性的密钥。正确的实现可能不支持许多密码套件。例如，匿名Diffie Hellman被强烈劝阻，因为它无法阻止中间人攻击。应用程序还应强制执行最小和最大密钥大小。例如，包含512位RSA密钥或签名的证书链不适用于高安全性应用程序。
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
实施经验表明，早期TLS规范的某些部分不容易理解，并且一直是互操作性和安全问题的根源。这些地区中的许多地区都有
been clarified in this document, but this appendix contains a short list of the most important things that require special attention from implementors.
本文档对此进行了澄清，但本附录包含了需要实施者特别注意的最重要事项的简短列表。
TLS protocol issues:
TLS协议问题：
- Do you correctly handle handshake messages that are fragmented to multiple TLS records (see Section 6.2.1)? Including corner cases like a ClientHello that is split to several small fragments? Do you fragment handshake messages that exceed the maximum fragment size? In particular, the certificate and certificate request handshake messages can be large enough to require fragmentation.
- 您是否正确处理分段为多个TLS记录的握手消息（参见第6.2.1节）？包括像ClientHello这样被分割成几个小碎片的角落案例？是否对超过最大片段大小的握手消息进行分段？特别是，证书和证书请求握手消息可能大到需要分段。
- Do you ignore the TLS record layer version number in all TLS records before ServerHello (see Appendix E.1)?
- 您是否忽略ServerHello之前所有TLS记录中的TLS记录层版本号（参见附录E.1）？
- Do you handle TLS extensions in ClientHello correctly, including omitting the extensions field completely?
- 您是否正确处理ClientHello中的TLS扩展，包括完全省略extensions字段？
- Do you support renegotiation, both client and server initiated? While renegotiation is an optional feature, supporting it is highly recommended.
- 您是否支持客户机和服务器发起的重新协商？虽然重新协商是可选功能，但强烈建议支持它。
- 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 7.4.6)?
- 当服务器已请求客户端证书，但没有合适的证书可用时，您是否正确地发送空证书消息，而不是忽略整个消息（请参阅第7.4.6节）？
Cryptographic details:
加密详细信息：
- In the RSA-encrypted Premaster Secret, do you correctly send and verify the version number? When an error is encountered, do you continue the handshake to avoid the Bleichenbacher attack (see Section 7.4.7.1)?
- 在RSA加密的Premaster机密中，是否正确发送和验证版本号？遇到错误时，您是否继续握手以避免Bleichenbacher攻击（参见第7.4.7.1节）？
- What countermeasures do you use to prevent timing attacks against RSA decryption and signing operations (see Section 7.4.7.1)?
- 您使用什么对策来防止针对RSA解密和签名操作的定时攻击（请参阅第7.4.7.1节）？
- When verifying RSA signatures, do you accept both NULL and missing parameters (see Section 4.7)? Do you verify that the RSA padding doesn't have additional data after the hash value? [FI06]
- 验证RSA签名时，是否同时接受空参数和缺少的参数（请参见第4.7节）？是否验证RSA填充在哈希值之后没有其他数据？[图06]
- When using Diffie-Hellman key exchange, do you correctly strip leading zero bytes from the negotiated key (see Section 8.1.2)?
- 使用Diffie-Hellman密钥交换时，您是否正确地从协商密钥中去掉前导零字节（参见第8.1.2节）？
- Does your TLS client check that the Diffie-Hellman parameters sent by the server are acceptable (see Section F.1.1.3)?
- 您的TLS客户端是否检查服务器发送的Diffie-Hellman参数是否可接受（参见第F.1.1.3节）？
- How do you generate unpredictable IVs for CBC mode ciphers (see Section 6.2.3.2)?
- 如何为CBC模式密码生成不可预测的IVs（见第6.2.3.2节）？
- Do you accept long CBC mode padding (up to 255 bytes; see Section 6.2.3.2)?
- 是否接受长CBC模式填充（最多255字节；请参阅第6.2.3.2节）？
- How do you address CBC mode timing attacks (Section 6.2.3.2)?
- 如何应对CBC模式定时攻击（第6.2.3.2节）？
- Do you use a strong and, most importantly, properly seeded random number generator (see Appendix D.1) for generating the premaster secret (for RSA key exchange), Diffie-Hellman private values, the DSA "k" parameter, and other security-critical values?
- 您是否使用一个强大且最重要的、正确播种的随机数生成器（参见附录D.1）来生成premaster机密（用于RSA密钥交换）、Diffie-Hellman私有值、DSA“k”参数和其他安全关键值？
Since there are various versions of TLS (1.0, 1.1, 1.2, and any future versions) and SSL (2.0 and 3.0), means are needed to negotiate the specific protocol version to use. The TLS protocol provides a built-in mechanism for version negotiation so as not to bother other protocol components with the complexities of version selection.
由于有不同版本的TLS（1.0、1.1、1.2和任何未来版本）和SSL（2.0和3.0），因此需要协商要使用的特定协议版本。TLS协议为版本协商提供了内置机制，这样就不会因为版本选择的复杂性而影响其他协议组件。
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible, and the client supports the highest protocol version available in the server.
TLS版本1.0、1.1和1.2以及SSL 3.0非常相似，并且使用兼容的ClientHello消息；因此，支持所有这些都相对容易。类似地，只要ClientHello格式保持兼容，并且客户端支持服务器中可用的最高协议版本，服务器就可以轻松处理尝试使用TLS未来版本的客户端。
A TLS 1.2 client who wishes to negotiate with such older servers will send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in ClientHello.client_version. If the server does not support this version, 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.
希望与这些旧服务器协商的TLS 1.2客户端将发送一个正常的TLS 1.2 ClientHello，其中包含ClientHello.client_版本中的{3,3}（TLS 1.2）。如果服务器不支持此版本，它将使用包含旧版本号的ServerHello进行响应。如果客户同意使用此版本，则协商将根据协商协议进行。
If the version chosen by the server is not supported by the client (or not acceptable), the client MUST send a "protocol_version" alert message and close the connection.
如果客户端不支持服务器选择的版本（或不可接受），则客户端必须发送“protocol_version”警报消息并关闭连接。
If a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server.
如果TLS服务器收到的ClientHello包含的版本号大于服务器支持的最高版本，则必须根据服务器支持的最高版本进行回复。
A TLS server can also receive a ClientHello containing a version number smaller than the highest supported version. If the server wishes to negotiate with old clients, it will proceed as appropriate
TLS服务器还可以接收包含版本号小于支持的最高版本的ClientHello。如果服务器希望与旧客户端协商，它将根据需要继续进行
for the highest version supported by the server that is not greater than ClientHello.client_version. For example, if the server supports TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If server supports (or is willing to use) only versions greater than client_version, it MUST send a "protocol_version" alert message and close the connection.
用于服务器支持的不大于ClientHello.client_版本的最高版本。例如，如果服务器支持TLS 1.0、1.1和1.2，并且客户端_版本为TLS 1.0，则服务器将继续使用TLS 1.0 ServerHello。如果服务器只支持（或愿意使用）高于客户端\u版本的版本，则必须发送“协议\u版本”警报消息并关闭连接。
Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol.
只要客户机已经知道服务器已知的最高协议版本（例如，在恢复会话时），它就应该在该本机协议中启动连接。
Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse the connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client.
注意：已知某些服务器实现不正确地实现版本协商。例如，有些有缺陷的TLS 1.0服务器在客户机提供比TLS 1.0更新的版本时只是关闭连接。此外，众所周知，如果ClientHello中包含任何TLS扩展，某些服务器将拒绝连接。与这些有缺陷的服务器的互操作性是一个复杂的主题，超出了本文的范围，可能需要客户端多次尝试连接。
Earlier versions of the TLS specification were not fully clear on what the record layer version number (TLSPlaintext.version) should contain when sending ClientHello (i.e., before it is known which version of the protocol will be employed). Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello.
TLS规范的早期版本对于发送ClientHello时记录层版本号（TLSPlaintext.version）应包含的内容并不完全清楚（即，在知道将使用哪个版本的协议之前）。因此，符合此规范的TLS服务器必须接受任何值{03，XX}作为ClientHello的记录层版本号。
TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers, but this is a complex topic beyond the scope of this document.
希望与旧服务器协商的TLS客户端可以发送任何值{03，XX}作为记录层版本号。典型的值是{03,00}，客户端支持的最低版本号，以及ClientHello.client_version的值。没有一个单一的值可以保证与所有旧服务器的互操作性，但这是一个复杂的主题，超出了本文档的范围。
TLS 1.2 clients that wish to support SSL 2.0 servers MUST send version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST contain the same version number as would be used for ordinary ClientHello, and MUST encode the supported TLS cipher suites in the CIPHER-SPECS-DATA field as described below.
希望支持SSL 2.0服务器的TLS 1.2客户端必须发送[SSL2]中定义的版本2.0 CLIENT-HELLO消息。消息必须包含与普通ClientHello相同的版本号，并且必须在cipher-SPECS-DATA字段中对支持的TLS密码套件进行编码，如下所述。
Warning: The ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste, since the newer ClientHello format provides better mechanisms for moving to newer versions and negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
警告：由于较新的ClientHello格式为移动到较新版本和协商扩展提供了更好的机制，因此发送版本2.0 CLIENT-HELLO消息的功能将被逐步取消。TLS 1.2客户端不应支持SSL 2.0。
However, even TLS servers that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO messages. The message is presented below in sufficient detail for TLS server implementors; the true definition is still assumed to be [SSL2].
但是，即使不支持SSL 2.0的TLS服务器也可能接受版本2.0的客户机HELLO消息。下面为TLS服务器实现者提供了足够详细的信息；真正的定义仍然假定为[SSL2]。
For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same way as a ClientHello with a "null" compression method and no extensions. Note that this message MUST be sent directly on the wire, not wrapped as a TLS record. For the purposes of calculating Finished and CertificateVerify, the msg_length field is not considered to be a part of the handshake message.
出于协商目的，2.0 CLIENT-HELLO的解释方式与ClientHello的解释方式相同，它使用“null”压缩方法，没有扩展。请注意，此消息必须直接通过导线发送，而不是包装为TLS记录。为了计算Finished和CertificateVerify，msg_长度字段不被视为握手消息的一部分。
uint8 V2CipherSpec[3];
struct {
uint16 msg_length;
uint8 msg_type;
Version version;
uint16 cipher_spec_length;
uint16 session_id_length;
uint16 challenge_length;
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
opaque session_id[V2ClientHello.session_id_length];
opaque challenge[V2ClientHello.challenge_length;
} V2ClientHello;
uint8 V2CipherSpec[3];
struct {
uint16 msg_length;
uint8 msg_type;
Version version;
uint16 cipher_spec_length;
uint16 session_id_length;
uint16 challenge_length;
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
opaque session_id[V2ClientHello.session_id_length];
opaque challenge[V2ClientHello.challenge_length;
} V2ClientHello;
msg_length The highest bit MUST be 1; the remaining bits contain the length of the following data in bytes.
msg_长度最高位必须为1；其余位包含以下数据的长度（以字节为单位）。
msg_type This field, in conjunction with the version field, identifies a version 2 ClientHello message. The value MUST be 1.
msg_type此字段与版本字段一起标识版本2 ClientHello消息。该值必须为1。
version Equal to ClientHello.client_version.
版本等于ClientHello.client_版本。
cipher_spec_length This field is the total length of the field cipher_specs. It cannot be zero and MUST be a multiple of the V2CipherSpec length (3).
密码规格长度此字段是字段密码规格的总长度。它不能为零，并且必须是V2CipherSpec长度（3）的倍数。
session_id_length This field MUST have a value of zero for a client that claims to support TLS 1.2.
会话\u id\u长度对于声称支持TLS 1.2的客户端，此字段的值必须为零。
challenge_length The length in bytes of the client's challenge to the server to authenticate itself. Historically, permissible values are between 16 and 32 bytes inclusive. When using the SSLv2 backward-compatible handshake the client SHOULD use a 32-byte challenge.
challenge_length客户端向服务器发出的验证自身身份的质询的长度（以字节为单位）。历史上，允许的值介于16和32字节之间（含16和32字节）。使用SSLv2向后兼容握手时，客户端应使用32字节的质询。
cipher_specs This is a list of all CipherSpecs the client is willing and able to use. In addition to the 2.0 cipher specs defined in [SSL2], this includes the TLS cipher suites normally sent in ClientHello.cipher_suites, with each cipher suite prefixed by a zero byte. For example, the TLS cipher suite {0x00,0x0A} would be sent as {0x00,0x00,0x0A}.
密码规格这是客户愿意并能够使用的所有密码规格的列表。除了[SSL2]中定义的2.0密码规范外，这还包括通常在ClientHello.cipher_套件中发送的TLS密码套件，每个密码套件的前缀为零字节。例如，TLS密码套件{0x00,0x0A}将作为{0x00,0x00,0x0A}发送。
session_id This field MUST be empty.
会话id此字段必须为空。
challenge Corresponds to ClientHello.random. If the challenge length is less than 32, the TLS server will pad the data with leading (note: not trailing) zero bytes to make it 32 bytes long.
挑战对应于ClientHello.random。如果质询长度小于32，TLS服务器将使用前导（注意：不是尾随）零字节填充数据，使其长度为32字节。
Note: Requests to resume a TLS session MUST use a TLS client hello.
注意：恢复TLS会话的请求必须使用TLS客户端。
When TLS clients fall back to Version 2.0 compatibility mode, they MUST use special PKCS#1 block formatting. This is done so that TLS servers will reject Version 2.0 sessions with TLS-capable clients.
当TLS客户端退回到版本2.0兼容模式时，它们必须使用特殊的PKCS#1块格式。这样做的目的是，TLS服务器将拒绝具有TLS功能的客户端的2.0版会话。
When a client negotiates SSL 2.0 but also supports TLS, it MUST set the right-hand (least-significant) 8 random bytes of the PKCS padding (not including the terminal null of the padding) for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random).
当客户机协商SSL 2.0但也支持TLS时，它必须将PKCS填充的右侧（最低有效）8个随机字节（不包括填充的终端null）设置为0x03（其他填充字节是随机的），以便对客户机主密钥的ENCRYPTED-KEY-DATA字段进行RSA加密。
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding bytes are 0x03. If they are not, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match). Note that reporting the error situation to the client could make the server vulnerable to attacks described in [BLEI].
当支持TLS的服务器协商SSL 2.0时，在解密加密的密钥数据字段后，应检查这8个填充字节是否为0x03。如果没有，服务器应该为SECRET-KEY-DATA生成一个随机值，并继续握手（由于密钥不匹配，握手最终会失败）。请注意，向客户端报告错误情况可能会使服务器容易受到[BLEI]中所述的攻击。
The TLS protocol is designed to establish a secure connection between a client and a server communicating over an insecure channel. This document makes several traditional assumptions, including that attackers have substantial computational resources and cannot obtain secret information from sources outside the protocol. Attackers are assumed to have the ability to capture, modify, delete, replay, and otherwise tamper with messages sent over the communication channel. This appendix outlines how TLS has been designed to resist a variety of attacks.
TLS协议旨在通过不安全通道在客户端和服务器之间建立安全连接。本文档做出了一些传统假设，包括攻击者拥有大量计算资源，无法从协议之外的来源获取机密信息。假定攻击者能够捕获、修改、删除、重播或以其他方式篡改通过通信通道发送的消息。本附录概述了TLS是如何设计来抵御各种攻击的。
The handshake protocol is responsible for selecting a cipher spec and generating a master secret, which together comprise the primary cryptographic parameters associated with a secure session. The handshake protocol can also optionally authenticate parties who have certificates signed by a trusted certificate authority.
握手协议负责选择密码规范并生成主密钥，主密钥共同包括与安全会话相关联的主要密码参数。握手协议还可以选择性地对拥有由可信证书颁发机构签署的证书的各方进行身份验证。
TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked.
TLS支持三种身份验证模式：双方身份验证、未经身份验证的客户端的服务器身份验证和完全匿名。只要服务器经过身份验证，通道就可以安全地抵御中间人攻击，但完全匿名会话本身就容易受到此类攻击。匿名服务器无法对客户端进行身份验证。如果服务器经过身份验证，则其证书消息必须提供一个有效的证书链，指向可接受的证书颁发机构。类似地，经过身份验证的客户端必须向服务器提供可接受的证书。各方负责验证另一方的证书是否有效且未过期或被撤销。
The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret (see Section 8.1). The master_secret is required to generate the Finished messages, encryption keys, and MAC keys (see Sections 7.4.9 and 6.3). By sending a correct Finished message, parties thus prove that they know the correct pre_master_secret.
密钥交换过程的总体目标是创建通信方而非攻击者所知的pre_master_秘密。pre_master_secret将用于生成master_secret（参见第8.1节）。生成完成的消息、加密密钥和MAC密钥需要主密钥（见第7.4.9节和第6.3节）。通过发送正确的完成消息，双方证明他们知道正确的pre_master_机密。
Completely anonymous sessions can be established using Diffie-Hellman for key exchange. The server's public parameters are contained in the server key exchange message, and the client's are sent in the
可以使用Diffie Hellman为密钥交换建立完全匿名会话。服务器的公共参数包含在服务器密钥交换消息中，客户端的公共参数在
client key exchange message. Eavesdroppers who do not know the private values should not be able to find the Diffie-Hellman result (i.e., the pre_master_secret).
客户端密钥交换消息。不知道私有值的窃听者不应该能够找到Diffie Hellman结果（即pre_master_secret）。
Warning: Completely anonymous connections only provide protection against passive eavesdropping. Unless an independent tamper-proof channel is used to verify that the Finished messages were not replaced by an attacker, server authentication is required in environments where active man-in-the-middle attacks are a concern.
警告：完全匿名连接仅提供被动窃听保护。除非使用独立的防篡改通道来验证完成的消息是否未被攻击者替换，否则在存在中间人攻击的环境中，需要进行服务器身份验证。
With RSA, key exchange and server authentication are combined. The public key is contained in the server's certificate. Note that compromise of the server's static RSA key results in a loss of confidentiality for all sessions protected under that static key. TLS users desiring Perfect Forward Secrecy should use DHE cipher suites. The damage done by exposure of a private key can be limited by changing one's private key (and certificate) frequently.
使用RSA，密钥交换和服务器身份验证结合在一起。公钥包含在服务器的证书中。请注意，服务器的静态RSA密钥泄露会导致受该静态密钥保护的所有会话的机密性丢失。希望实现完美前向保密的TLS用户应使用DHE密码套件。通过频繁更改私钥（和证书），可以限制私钥暴露造成的损害。
After verifying the server's certificate, the client encrypts a pre_master_secret with the server's public key. By successfully decoding the pre_master_secret and producing a correct Finished message, the server demonstrates that it knows the private key corresponding to the server certificate.
在验证服务器的证书后，客户端使用服务器的公钥加密pre_master_密钥。通过成功解码pre_master_secret并生成正确的完成消息，服务器证明它知道与服务器证书对应的私钥。
When RSA is used for key exchange, clients are authenticated using the certificate verify message (see Section 7.4.8). The client signs a value derived from all preceding handshake messages. These handshake messages include the server certificate, which binds the signature to the server, and ServerHello.random, which binds the signature to the current handshake process.
当RSA用于密钥交换时，使用证书验证消息对客户端进行身份验证（请参见第7.4.8节）。客户端对从前面所有握手消息派生的值进行签名。这些握手消息包括将签名绑定到服务器的服务器证书和将签名绑定到当前握手过程的ServerHello.random。
When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSA or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server.
使用Diffie-Hellman密钥交换时，服务器可以提供包含固定Diffie-Hellman参数的证书，也可以使用服务器密钥交换消息发送一组使用DSA或RSA证书签名的临时Diffie-Hellman参数。临时参数在签名之前会使用hello.random值进行散列，以确保攻击者不会重播旧参数。在这两种情况下，客户机都可以验证证书或签名，以确保参数属于服务器。
If the client has a certificate containing fixed Diffie-Hellman parameters, its certificate contains the information required to complete the key exchange. Note that in this case the client and server will generate the same Diffie-Hellman result (i.e.,
如果客户机具有包含固定Diffie-Hellman参数的证书，则其证书包含完成密钥交换所需的信息。请注意，在这种情况下，客户端和服务器将生成相同的Diffie-Hellman结果（即。，
pre_master_secret) every time they communicate. To prevent the pre_master_secret from staying in memory any longer than necessary, it should be converted into the master_secret as soon as possible. Client Diffie-Hellman parameters must be compatible with those supplied by the server for the key exchange to work.
每次他们交流时，都要事先掌握秘密。为了防止pre_master_secret在内存中停留的时间超过需要，应尽快将其转换为master_secret。客户端Diffie-Hellman参数必须与服务器提供的参数兼容，密钥交换才能工作。
If the client has a standard DSA or RSA certificate or is unauthenticated, it sends a set of temporary parameters to the server in the client key exchange message, then optionally uses a certificate verify message to authenticate itself.
如果客户端具有标准DSA或RSA证书或未经身份验证，则会在客户端密钥交换消息中向服务器发送一组临时参数，然后可选地使用证书验证消息对自身进行身份验证。
If the same DH keypair is to be used for multiple handshakes, either because the client or server has a certificate containing a fixed DH keypair or because the server is reusing DH keys, care must be taken to prevent small subgroup attacks. Implementations SHOULD follow the guidelines found in [SUBGROUP].
如果由于客户端或服务器具有包含固定DH密钥对的证书，或者由于服务器正在重用DH密钥，因此同一DH密钥对将用于多次握手，则必须小心防止小子组攻击。实施应遵循[SUBGROUP]中的指导原则。
Small subgroup attacks are most easily avoided by using one of the DHE cipher suites and generating a fresh DH private key (X) for each handshake. If a suitable base (such as 2) is chosen, g^X mod p can be computed very quickly; therefore, the performance cost is minimized. Additionally, using a fresh key for each handshake provides Perfect Forward Secrecy. Implementations SHOULD generate a new X for each handshake when using DHE cipher suites.
通过使用一个DHE密码套件并为每次握手生成一个新的DH私钥（X），最容易避免小子组攻击。如果选择合适的基数（如2），则可以非常快速地计算g^X mod p；因此，性能成本最小化。此外，为每次握手使用新密钥提供了完美的前向保密性。当使用DHE密码套件时，实现应该为每次握手生成一个新的X。
Because TLS allows the server to provide arbitrary DH groups, the client should verify that the DH group is of suitable size as defined by local policy. The client SHOULD also verify that the DH public exponent appears to be of adequate size. [KEYSIZ] provides a useful guide to the strength of various group sizes. The server MAY choose to assist the client by providing a known group, such as those defined in [IKEALG] or [MODP]. These can be verified by simple comparison.
由于TLS允许服务器提供任意DH组，因此客户端应验证DH组是否具有本地策略定义的适当大小。客户还应验证DH public Index的大小是否合适。[KEYSIZ]提供了一个有用的指南，可以了解各种组大小的强度。服务器可以选择通过提供已知组来帮助客户端，例如[IKEALG]或[MODP]中定义的组。这些可以通过简单的比较来验证。
Because TLS includes substantial improvements over SSL Version 2.0, attackers may try to make TLS-capable clients and servers fall back to Version 2.0. This attack can occur if (and only if) two TLS-capable parties use an SSL 2.0 handshake.
由于TLS对SSL 2.0版进行了实质性改进，攻击者可能会试图使支持TLS的客户端和服务器退回到2.0版。如果（且仅当）两个支持TLS的方使用SSL 2.0握手，则可能发生此攻击。
Although the solution using non-random PKCS #1 block type 2 message padding is inelegant, it provides a reasonably secure way for Version 3.0 servers to detect the attack. This solution is not secure against attackers who can brute-force the key and substitute a new ENCRYPTED-KEY-DATA message containing the same key (but with normal padding) before the application-specified wait threshold has expired. Altering the padding of the least-significant 8 bytes of the PKCS
尽管使用非随机PKCS#1 block type 2消息填充的解决方案并不美观，但它为3.0版服务器提供了一种合理安全的方法来检测攻击。此解决方案不安全，攻击者可以在应用程序指定的等待阈值过期之前强行使用密钥并替换包含相同密钥（但具有正常填充）的新加密密钥数据消息。更改PKCS最低有效8字节的填充
padding does not impact security for the size of the signed hashes and RSA key lengths used in the protocol, since this is essentially equivalent to increasing the input block size by 8 bytes.
填充不会影响协议中使用的签名哈希和RSA密钥长度的安全性，因为这实际上相当于将输入块大小增加8个字节。
An attacker might try to influence the handshake exchange to make the parties select different encryption algorithms than they would normally choose.
攻击者可能试图影响握手交换，使双方选择不同于通常选择的加密算法。
For this attack, an attacker must actively change one or more handshake messages. If this occurs, the client and server will compute different values for the handshake message hashes. As a result, the parties will not accept each others' Finished messages. Without the master_secret, the attacker cannot repair the Finished messages, so the attack will be discovered.
对于此攻击，攻击者必须主动更改一条或多条握手消息。如果发生这种情况，客户端和服务器将为握手消息哈希计算不同的值。因此，双方将不接受对方已完成的消息。如果没有master_secret，攻击者无法修复完成的消息，因此将发现攻击。
When a connection is established by resuming a session, new ClientHello.random and ServerHello.random values are hashed with the session's master_secret. Provided that the master_secret has not been compromised and that the secure hash operations used to produce the encryption keys and MAC keys are secure, the connection should be secure and effectively independent from previous connections. Attackers cannot use known encryption keys or MAC secrets to compromise the master_secret without breaking the secure hash operations.
当通过恢复会话建立连接时，新的ClientHello.random和ServerHello.random值将使用会话的master_secret散列。如果主密钥未被泄露，并且用于生成加密密钥和MAC密钥的安全哈希操作是安全的，则连接应该是安全的，并且有效地独立于以前的连接。攻击者不能使用已知的加密密钥或MAC机密泄露主密钥，而不破坏安全哈希操作。
Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake. An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired. Applications that may be run in relatively insecure environments should not write session IDs to stable storage.
除非客户端和服务器都同意，否则无法恢复会话。如果任何一方怀疑会话可能已被泄露，或者证书可能已过期或被吊销，则应强制进行完全握手。建议会话ID生命周期的上限为24小时，因为获得master_机密的攻击者可能能够模拟受攻击方，直到相应的会话ID失效。可能在相对不安全的环境中运行的应用程序不应将会话ID写入稳定的存储。
The master_secret is hashed with the ClientHello.random and ServerHello.random to produce unique data encryption keys and MAC secrets for each connection.
主密钥使用ClientHello.random和ServerHello.random散列，为每个连接生成唯一的数据加密密钥和MAC密钥。
Outgoing data is protected with a MAC before transmission. To prevent message replay or modification attacks, the MAC is computed from the MAC key, the sequence number, the message length, the
传出数据在传输前由MAC保护。为了防止消息重播或修改攻击，MAC由MAC密钥、序列号、消息长度和
message contents, and two fixed character strings. The message type field is necessary to ensure that messages intended for one TLS record layer client are not redirected to another. The sequence number ensures that attempts to delete or reorder messages will be detected. Since sequence numbers are 64 bits long, they should never overflow. Messages from one party cannot be inserted into the other's output, since they use independent MAC keys. Similarly, the server write and client write keys are independent, so stream cipher keys are used only once.
消息内容和两个固定字符串。message type字段是确保一个TLS记录层客户端的消息不会重定向到另一个客户端所必需的。序列号可确保检测到删除或重新排序邮件的尝试。由于序列号的长度为64位，因此它们永远不会溢出。来自一方的消息不能插入到另一方的输出中，因为它们使用独立的MAC密钥。类似地，服务器写入密钥和客户端写入密钥是独立的，因此流密码密钥只使用一次。
If an attacker does break an encryption key, all messages encrypted with it can be read. Similarly, compromise of a MAC key can make message-modification attacks possible. Because MACs are also encrypted, message-alteration attacks generally require breaking the encryption algorithm as well as the MAC.
如果攻击者确实破坏了加密密钥，则可以读取使用该密钥加密的所有消息。类似地，泄露MAC密钥可能导致消息修改攻击。由于MAC也是加密的，因此消息更改攻击通常需要破坏加密算法和MAC。
Note: MAC keys may be larger than encryption keys, so messages can remain tamper resistant even if encryption keys are broken.
注意：MAC密钥可能大于加密密钥，因此即使加密密钥被破坏，消息也可以保持防篡改。
[CBCATT] describes a chosen plaintext attack on TLS that depends on knowing the IV for a record. Previous versions of TLS [TLS1.0] used the CBC residue of the previous record as the IV and therefore enabled this attack. This version uses an explicit IV in order to protect against this attack.
[CBCATT]描述了对TLS的选择明文攻击，该攻击依赖于知道记录的IV。TLS[TLS1.0]的早期版本将先前记录的CBC剩余部分用作IV，因此启用了此攻击。此版本使用显式IV以防止此攻击。
TLS secures transmitted application data via the use of symmetric encryption and authentication functions defined in the negotiated cipher suite. The objective is to protect both the integrity and confidentiality of the transmitted data from malicious actions by active attackers in the network. It turns out that the order in which encryption and authentication functions are applied to the data plays an important role for achieving this goal [ENCAUTH].
TLS通过使用协商密码套件中定义的对称加密和身份验证功能来保护传输的应用程序数据。其目的是保护传输数据的完整性和机密性，使其免受网络中主动攻击者的恶意攻击。事实证明，加密和身份验证功能应用于数据的顺序对于实现这一目标起着重要作用[Enauth]。
The most robust method, called encrypt-then-authenticate, first applies encryption to the data and then applies a MAC to the ciphertext. This method ensures that the integrity and confidentiality goals are obtained with ANY pair of encryption and MAC functions, provided that the former is secure against chosen plaintext attacks and that the MAC is secure against chosen-message attacks. TLS uses another method, called authenticate-then-encrypt, in which first a MAC is computed on the plaintext and then the concatenation of plaintext and MAC is encrypted. This method has been proven secure for CERTAIN combinations of encryption functions and MAC functions, but it is not guaranteed to be secure in general.
最健壮的方法称为加密然后认证，首先对数据应用加密，然后对密文应用MAC。该方法确保通过任何一对加密和MAC功能实现完整性和机密性目标，前提是前者对选择的明文攻击是安全的，并且MAC对选择的消息攻击是安全的。TLS使用另一种方法，称为先验证后加密，其中首先在明文上计算MAC，然后对明文和MAC的串联进行加密。这种方法已被证明对加密功能和MAC功能的某些组合是安全的，但不能保证总体上是安全的。
In particular, it has been shown that there exist perfectly secure encryption functions (secure even in the information-theoretic sense) that combined with any secure MAC function, fail to provide the confidentiality goal against an active attack. Therefore, new cipher suites and operation modes adopted into TLS need to be analyzed under the authenticate-then-encrypt method to verify that they achieve the stated integrity and confidentiality goals.
特别是，已经证明存在完全安全的加密函数（即使在信息理论意义上也是安全的），这些函数与任何安全的MAC函数相结合，无法提供针对主动攻击的机密性目标。因此，TLS中采用的新密码套件和操作模式需要在先验证后加密的方法下进行分析，以验证它们是否达到了规定的完整性和机密性目标。
Currently, the security of the authenticate-then-encrypt method has been proven for some important cases. One is the case of stream ciphers in which a computationally unpredictable pad of the length of the message, plus the length of the MAC tag, is produced using a pseudorandom generator and this pad is exclusive-ORed with the concatenation of plaintext and MAC tag. The other is the case of CBC mode using a secure block cipher. In this case, security can be shown if one applies one CBC encryption pass to the concatenation of plaintext and MAC and uses a new, independent, and unpredictable IV for each new pair of plaintext and MAC. In versions of TLS prior to 1.1, CBC mode was used properly EXCEPT that it used a predictable IV in the form of the last block of the previous ciphertext. This made TLS open to chosen plaintext attacks. This version of the protocol is immune to those attacks. For exact details in the encryption modes proven secure, see [ENCAUTH].
目前，在一些重要的情况下，验证然后加密方法的安全性已经得到证明。一种是流密码的情况，其中使用伪随机生成器生成消息长度加上MAC标记长度的计算上不可预测的pad，并且该pad通过明文和MAC标记的串联进行异或。另一种是使用安全分组密码的CBC模式。在这种情况下，如果将一个CBC加密过程应用于明文和MAC的串联，并对每对新的明文和MAC使用新的、独立的且不可预测的IV，则可以显示安全性。在1.1之前的TLS版本中，CBC模式被正确地使用，除了它使用了以先前密文的最后一个块的形式出现的可预测IV。这使得TLS对选定的明文攻击开放。此版本的协议不受这些攻击的影响。有关经验证安全的加密模式的确切详细信息，请参阅[EnCuth]。
TLS is susceptible to a number of denial-of-service (DoS) attacks. In particular, an attacker who initiates a large number of TCP connections can cause a server to consume large amounts of CPU for doing RSA decryption. However, because TLS is generally used over TCP, it is difficult for the attacker to hide his point of origin if proper TCP SYN randomization is used [SEQNUM] by the TCP stack.
TLS容易受到许多拒绝服务（DoS）攻击。特别是，发起大量TCP连接的攻击者可能会导致服务器为执行RSA解密而消耗大量CPU。但是，由于TLS通常通过TCP使用，因此如果TCP堆栈使用适当的TCP SYN随机化[SEQNUM]，攻击者很难隐藏其原点。
Because TLS runs over TCP, it is also susceptible to a number of DoS attacks on individual connections. In particular, attackers can forge RSTs, thereby terminating connections, or forge partial TLS records, thereby causing the connection to stall. These attacks cannot in general be defended against by a TCP-using protocol. Implementors or users who are concerned with this class of attack should use IPsec AH [AH] or ESP [ESP].
由于TLS通过TCP运行，因此它也容易受到对单个连接的大量DoS攻击。特别是，攻击者可以伪造RST，从而终止连接，或者伪造部分TLS记录，从而导致连接暂停。这些攻击通常不能通过TCP使用协议进行防御。与此类攻击相关的实现者或用户应使用IPsec AH[AH]或ESP[ESP]。
For TLS to be able to provide a secure connection, both the client and server systems, keys, and applications must be secure. In addition, the implementation must be free of security errors.
为了使TLS能够提供安全连接，客户端和服务器系统、密钥和应用程序都必须是安全的。此外，实现必须没有安全错误。
The system is only as strong as the weakest key exchange and authentication algorithm supported, and only trustworthy cryptographic functions should be used. Short public keys and anonymous servers should be used with great caution. Implementations and users must be careful when deciding which certificates and certificate authorities are acceptable; a dishonest certificate authority can do tremendous damage.
该系统仅与所支持的最薄弱的密钥交换和身份验证算法一样强大，并且只能使用可靠的加密功能。使用短公钥和匿名服务器时应格外小心。在决定哪些证书和证书颁发机构是可接受的时，实现和用户必须小心；不诚实的证书颁发机构会造成巨大的损失。
Normative References
规范性引用文件
[AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)" FIPS 197. November 26, 2001.
[AES]国家标准与技术研究所，“高级加密标准（AES）规范”FIPS 197。2001年11月26日。
[3DES] National Institute of Standards and Technology, "Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher", NIST Special Publication 800-67, May 2004.
[3DES]国家标准与技术研究所，“三重数据加密算法（TDEA）分组密码建议”，NIST特别出版物800-67，2004年5月。
[DSS] NIST FIPS PUB 186-2, "Digital Signature Standard", National Institute of Standards and Technology, U.S. Department of Commerce, 2000.
[DSS]NIST FIPS PUB 186-2，“数字签名标准”，美国商务部国家标准与技术研究所，2000年。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS1]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[PKIX]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd ed.", Published by John Wiley & Sons, Inc. 1996.
[SCH]B.Schneier。“应用密码学：C语言中的协议、算法和源代码，第二版”，约翰·威利父子公司出版，1996年。
[SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National Institute of Standards and Technology, U.S. Department of Commerce, August 2002.
[SHS]NIST FIPS PUB 180-2，“安全哈希标准”，美国商务部国家标准与技术研究所，2002年8月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ]Bradner，S.，“在RFC中用于指示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation.
[X680]ITU-T建议X.680（2002）| ISO/IEC 8824-1:2002，信息技术-抽象语法符号1（ASN.1）：基本符号规范。
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X690]ITU-T建议X.690（2002）| ISO/IEC 8825-1:2002，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范。
Informative References
资料性引用
[AEAD] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, January 2008.
[AEAD]McGrew，D.，“认证加密的接口和算法”，RFC 5116，2008年1月。
[AH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1" in Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: 1-12, 1998.
[BLEI]Bleichenbacher D.，“针对基于RSA加密标准PKCS#1的协议的选择密文攻击”，载于《密码学进展——CRYPTO'98》，LNCS第1462卷，第1-12页，1998年。
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: Problems and Countermeasures", http://www.openssl.org/~bodo/tls-cbc.txt.
[CBCATT]Moeller，B.，“SSL/TLS中CBC密码套件的安全性：问题与对策”，http://www.openssl.org/~bodo/tls-cbc.txt。
[CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, "Password Interception in a SSL/TLS Channel", Advances in Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003.
[CBCTIME]Canvel，B.，Hiltgen，A.，Vaudenay，S.，和M.Vuagnoux，“SSL/TLS信道中的密码拦截”，密码学进展——加密2003，LNCS第27292003卷。
[CCM] "NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality",
http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf
[CCM] "NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality",
http://csrc.nist.gov/publications/nistpubs/800-38C/
SP800-38C.pdf
[DES] National Institute of Standards and Technology, "Data Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
[DES]国家标准与技术研究所，“数据加密标准（DES）”，FIPS PUB 46-3，1999年10月。
[DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard", National Institute of Standards and Technology, U.S. Department of Commerce, 2006.
[DSS-3]NIST FIPS PUB 186-3草案，“数字签名标准”，美国商务部国家标准与技术研究所，2006年。
[ECDSA] American National Standards Institute, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS X9.62-2005, November 2005.
[ECDSA]美国国家标准协会，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANS X9.62-2005，2005年11月。
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)", Crypto 2001.
[Encouth]Krawczyk，H.，“保护通信的加密和认证顺序（或：SSL有多安全？），《加密2001》。
[ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[ESP]Kent，S.，“IP封装安全有效负载（ESP）”，RFC 4303，2005年12月。
[FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on implementation error", ietf-openpgp@imc.org mailing list, 27 August 2006, http://www.imc.org/ietf-openpgp/ mail-archive/msg14307.html.
[FI06]Hal Finney，“基于实现错误的Bleichenbacher RSA签名伪造”，ietf-openpgp@imc.org邮寄名单，2006年8月27日，http://www.imc.org/ietf-openpgp/ 邮件存档/msg14307.html。
[GCM] Dworkin, M., NIST Special Publication 800-38D, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", November 2007.
[GCM]Dworkin，M.，NIST特别出版物800-38D，“分组密码操作模式建议：Galois/计数器模式（GCM）和GMAC”，2007年11月。
[IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
[IKEALG]Schiller，J.，“互联网密钥交换版本2（IKEv2）中使用的加密算法”，RFC 4307，2005年12月。
[KEYSIZ] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[KEYSIZ]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, March 2003.
[KPR03]Klima，V.，Pokorny，O.，Rosa，T.，“在SSL/TLS中攻击基于RSA的会话”，http://eprint.iacr.org/2003/052/，2003年3月。
[MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[MODP]Kivinen，T.和M.Kojo，“因特网密钥交换（IKE）的更模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax Standard", version 1.5, November 1993.
[PKCS6]RSA实验室，“PKCS#6:RSA扩展证书语法标准”，1.5版，1993年11月。
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax Standard", version 1.5, November 1993.
[PKCS7]RSA实验室，“PKCS#7:RSA加密消息语法标准”，1.5版，1993年11月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004.
[RFC3749]Hollenbeck，S.，“传输层安全协议压缩方法”，RFC 3749，2004年5月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 4366，2006年4月。
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126.
[RSA]R.Rivest，A.Shamir和L.M.Adleman，“获取数字签名和公钥密码系统的方法”，ACM通信，v。21，n。1978年2月2日，第120-126页。
[SEQNUM] Bellovin, S., "Defending Against Sequence Number Attacks", RFC 1948, May 1996.
[SEQNUM]Bellovin，S.，“防御序列号攻击”，RFC 1948，1996年5月。
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995.
[SSL2]希克曼，基普，“SSL协议”，网景通信公司，1995年2月9日。
[SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996.
[SSL3]A.Freier，P.Karlton和P.Kocher，“SSL 3.0协议”，网景通信公司，1996年11月18日。
[SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000.
[分组]Zuccherato，R.，“避免S/MIME Diffie-Hellman密钥协商方法的“小分组”攻击的方法”，RFC 27852000年3月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are practical", USENIX Security Symposium 2003.
[定时]Boneh，D.，Brumley，D.，“远程定时攻击是切实可行的”，USENIX安全研讨会2003。
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[TLSAES]Chown，P.，“用于传输层安全（TLS）的高级加密标准（AES）密码套件”，RFC 32682002年6月。
[TLSECC] 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, May 2006.
[TLSECC]Blake Wilson，S.，Bolyard，N.，Gupta，V.，Hawk，C.，和B.Moeller，“用于传输层安全（TLS）的椭圆曲线加密（ECC）密码套件”，RFC 4492，2006年5月。
[TLSEXT] Eastlake, D., 3rd, "Transport Layer Security (TLS) Extensions: Extension Definitions", Work in Progress, February 2008.
[TLSEXT]Eastlake，D.，第3期，“传输层安全（TLS）扩展：扩展定义”，正在进行的工作，2008年2月。
[TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport Layer Security (TLS) Authentication", RFC 5081, November 2007.
[TLSPGP]Mavrogiannopoulos，N.，“使用OpenPGP密钥进行传输层安全（TLS）认证”，RFC 5081，2007年11月。
[TLSPSK] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005.
[TLSPSK]Eronen，P.，Ed.，和H.Tschofenig，Ed.，“用于传输层安全（TLS）的预共享密钥密码套件”，RFC 4279，2005年12月。
[TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS1.0]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC 2246，1999年1月。
[TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS1.1]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[X501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993.
[X501]ITU-T建议X.501：信息技术-开放系统互连-目录：模型，1993年。
[XDR] Eisler, M., Ed., "XDR: External Data Representation Standard", STD 67, RFC 4506, May 2006.
[XDR]艾斯勒，M.，编辑，“XDR：外部数据表示标准”，STD 67，RFC 4506，2006年5月。
Working Group Information
工作组资料
The discussion list for the IETF TLS working group is located at the
e-mail address <tls@ietf.org>. Information on the group and
information on how to subscribe to the list is at
<https://www1.ietf.org/mailman/listinfo/tls>
The discussion list for the IETF TLS working group is located at the
e-mail address <tls@ietf.org>. Information on the group and
information on how to subscribe to the list is at
<https://www1.ietf.org/mailman/listinfo/tls>
Archives of the list can be found at:
<http://www.ietf.org/mail-archive/web/tls/current/index.html>
Archives of the list can be found at:
<http://www.ietf.org/mail-archive/web/tls/current/index.html>
Contributors
贡献者
Christopher Allen (co-editor of TLS 1.0) Alacrity Ventures ChristopherA@AlacrityManagement.com
克里斯托弗·艾伦（TLS1.0联合编辑）Alacrity VenturesChristopherA@AlacrityManagement.com
Martin Abadi University of California, Santa Cruz abadi@cs.ucsc.edu
马丁阿巴迪加利福尼亚大学，圣克鲁斯abadi@cs.ucsc.edu
Steven M. Bellovin Columbia University smb@cs.columbia.edu
史蒂文·M·贝洛文哥伦比亚大学smb@cs.columbia.edu
Simon Blake-Wilson BCI sblakewilson@bcisse.com
西蒙布莱克威尔逊sblakewilson@bcisse.com
Ran Canetti IBM canetti@watson.ibm.com
Ran Canetti IBMcanetti@watson.ibm.com
Pete Chown Skygate Technology Ltd pc@skygate.co.uk
彼得·周天门科技有限公司pc@skygate.co.uk
Taher Elgamal taher@securify.com Securify
塔赫尔·埃尔加马尔taher@securify.com安全化
Pasi Eronen pasi.eronen@nokia.com Nokia
帕西·艾隆·帕西。eronen@nokia.com诺基亚
Anil Gangolli anil@busybuddha.org
安尼尔·甘戈利anil@busybuddha.org
Kipp Hickman
基普·希克曼
Alfred Hoenes
阿尔弗雷德·霍恩斯
David Hopwood Independent Consultant david.hopwood@blueyonder.co.uk
大卫霍普伍德独立顾问大卫。hopwood@blueyonder.co.uk
Phil Karlton (co-author of SSLv3)
菲尔·卡尔顿（SSLv3的合著者）
Paul Kocher (co-author of SSLv3) Cryptography Research paul@cryptography.com
Paul Kocher（SSLv3的合著者）密码学研究paul@cryptography.com
Hugo Krawczyk IBM hugo@ee.technion.ac.il
雨果·克劳奇克hugo@ee.technion.ac.il
Jan Mikkelsen Transactionware janm@transactionware.com
Jan Mikkelsen交易软件janm@transactionware.com
Magnus Nystrom RSA Security magnus@rsasecurity.com
Magnus Nystrom RSA安全magnus@rsasecurity.com
Robert Relyea Netscape Communications relyea@netscape.com
罗伯特·雷耶网景通信公司relyea@netscape.com
Jim Roskind Netscape Communications jar@netscape.com
吉姆·罗斯金·网景通信公司jar@netscape.com
Michael Sabin
迈克尔·萨宾
Dan Simon Microsoft, Inc. dansimon@microsoft.com
丹·西蒙微软公司。dansimon@microsoft.com
Tom Weinstein
汤姆温斯坦
Tim Wright Vodafone timothy.wright@vodafone.com
蒂姆·赖特·沃达丰·蒂莫西。wright@vodafone.com
Editors' Addresses
编辑地址
Tim Dierks Independent EMail: tim@dierks.org
Tim Dierks独立电子邮件：tim@dierks.org
Eric Rescorla RTFM, Inc. EMail: ekr@rtfm.com
Eric Rescorla RTFM，Inc.电子邮件：ekr@rtfm.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.