Network Working Group T. Dierks
Request for Comments: 4346 Independent
Obsoletes: 2246 E. Rescorla
Category: Standards Track RTFM, Inc.
April 2006
Network Working Group T. Dierks
Request for Comments: 4346 Independent
Obsoletes: 2246 E. Rescorla
Category: Standards Track RTFM, Inc.
April 2006
The Transport Layer Security (TLS) Protocol Version 1.1
传输层安全（TLS）协议版本1.1
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document specifies Version 1.1 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.1版。TLS协议提供了互联网上的通信安全。该协议允许客户机/服务器应用程序以防止窃听、篡改或消息伪造的方式进行通信。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Differences from TLS 1.0 ...................................5
1.2. Requirements Terminology ...................................5
2. Goals ...........................................................5
3. Goals of This Document ..........................................6
4. Presentation Language ...........................................6
4.1. Basic Block Size ...........................................7
4.2. Miscellaneous ..............................................7
4.3. Vectors ....................................................7
4.4. Numbers ....................................................8
4.5. Enumerateds ................................................8
4.6. Constructed Types ..........................................9
4.6.1. Variants ...........................................10
4.7. Cryptographic Attributes ..................................11
4.8. Constants .................................................12
5. HMAC and the Pseudorandom Function .............................12
6. The TLS Record Protocol ........................................14
6.1. Connection States .........................................15
6.2. Record layer ..............................................17
6.2.1. Fragmentation ......................................17
6.2.2. Record Compression and Decompression ...............19
6.2.3. Record Payload Protection ..........................19
6.2.3.1. Null or Standard Stream Cipher ............20
6.2.3.2. CBC Block Cipher ..........................21
6.3. Key Calculation ...........................................24
7. The TLS Handshaking Protocols ..................................24
7.1. Change Cipher Spec Protocol ...............................25
7.2. Alert Protocol ............................................26
7.2.1. Closure Alerts .....................................27
7.2.2. Error Alerts .......................................28
7.3. Handshake Protocol Overview ...............................31
7.4. Handshake Protocol ........................................34
7.4.1. Hello Messages .....................................35
7.4.1.1. Hello request .............................35
7.4.1.2. Client Hello ..............................36
7.4.1.3. Server Hello ..............................39
7.4.2. Server Certificate .................................40
7.4.3. Server Key Exchange Message ........................42
7.4.4. Certificate request ................................44
7.4.5. Server Hello Done ..................................46
7.4.6. Client certificate .................................46
7.4.7. Client Key Exchange Message ........................47
7.4.7.1. RSA Encrypted Premaster Secret Message ....47
7.4.7.2. Client Diffie-Hellman Public Value ........50
7.4.8. Certificate verify .................................50
7.4.9. Finished ...........................................51
1. Introduction ....................................................4
1.1. Differences from TLS 1.0 ...................................5
1.2. Requirements Terminology ...................................5
2. Goals ...........................................................5
3. Goals of This Document ..........................................6
4. Presentation Language ...........................................6
4.1. Basic Block Size ...........................................7
4.2. Miscellaneous ..............................................7
4.3. Vectors ....................................................7
4.4. Numbers ....................................................8
4.5. Enumerateds ................................................8
4.6. Constructed Types ..........................................9
4.6.1. Variants ...........................................10
4.7. Cryptographic Attributes ..................................11
4.8. Constants .................................................12
5. HMAC and the Pseudorandom Function .............................12
6. The TLS Record Protocol ........................................14
6.1. Connection States .........................................15
6.2. Record layer ..............................................17
6.2.1. Fragmentation ......................................17
6.2.2. Record Compression and Decompression ...............19
6.2.3. Record Payload Protection ..........................19
6.2.3.1. Null or Standard Stream Cipher ............20
6.2.3.2. CBC Block Cipher ..........................21
6.3. Key Calculation ...........................................24
7. The TLS Handshaking Protocols ..................................24
7.1. Change Cipher Spec Protocol ...............................25
7.2. Alert Protocol ............................................26
7.2.1. Closure Alerts .....................................27
7.2.2. Error Alerts .......................................28
7.3. Handshake Protocol Overview ...............................31
7.4. Handshake Protocol ........................................34
7.4.1. Hello Messages .....................................35
7.4.1.1. Hello request .............................35
7.4.1.2. Client Hello ..............................36
7.4.1.3. Server Hello ..............................39
7.4.2. Server Certificate .................................40
7.4.3. Server Key Exchange Message ........................42
7.4.4. Certificate request ................................44
7.4.5. Server Hello Done ..................................46
7.4.6. Client certificate .................................46
7.4.7. Client Key Exchange Message ........................47
7.4.7.1. RSA Encrypted Premaster Secret Message ....47
7.4.7.2. Client Diffie-Hellman Public Value ........50
7.4.8. Certificate verify .................................50
7.4.9. Finished ...........................................51
8. Cryptographic Computations .....................................52
8.1. Computing the Master Secret ...............................52
8.1.1. RSA ................................................53
8.1.2. Diffie-Hellman .....................................53
9. Mandatory Cipher Suites ........................................53
10. Application Data Protocol .....................................53
11. Security Considerations .......................................53
12. IANA Considerations ...........................................54
A. Appendix - Protocol constant values ............................55
A.1. Record layer .........................................55
A.2. Change cipher specs message ..........................56
A.3. Alert messages .......................................56
A.4. Handshake protocol ...................................57
A.4.1. Hello messages .....................................57
A.4.2. Server authentication and key exchange messages ....58
A.4.3. Client authentication and key exchange messages ....59
A.4.4.Handshake finalization message ......................60
A.5. The CipherSuite ......................................60
A.6. The Security Parameters ..............................63
B. Appendix - Glossary ............................................64
C. Appendix - CipherSuite definitions .............................68
D. Appendix - Implementation Notes ................................69
D.1 Random Number Generation and Seeding ..................70
D.2 Certificates and authentication .......................70
D.3 CipherSuites ..........................................70
E. Appendix - Backward Compatibility With SSL .....................71
E.1. Version 2 client hello ...............................72
E.2. Avoiding man-in-the-middle version rollback ..........74
F. Appendix - Security analysis ...................................74
F.1. Handshake protocol ...................................74
F.1.1. Authentication and key exchange ....................74
F.1.1.1. Anonymous key exchange ...........................75
F.1.1.2. RSA key exchange and authentication ..............75
F.1.1.3. Diffie-Hellman key exchange with authentication ..76
F.1.2. Version rollback attacks ...........................77
F.1.3. Detecting attacks against the handshake protocol ...77
F.1.4. Resuming sessions ..................................78
F.1.5. MD5 and SHA ........................................78
F.2. Protecting application data ..........................78
F.3. Explicit IVs .........................................79
F.4 Security of Composite Cipher Modes ...................79
F.5 Denial of Service ....................................80
F.6. Final notes ..........................................80
Normative References ..............................................81
Informative References ............................................82
8. Cryptographic Computations .....................................52
8.1. Computing the Master Secret ...............................52
8.1.1. RSA ................................................53
8.1.2. Diffie-Hellman .....................................53
9. Mandatory Cipher Suites ........................................53
10. Application Data Protocol .....................................53
11. Security Considerations .......................................53
12. IANA Considerations ...........................................54
A. Appendix - Protocol constant values ............................55
A.1. Record layer .........................................55
A.2. Change cipher specs message ..........................56
A.3. Alert messages .......................................56
A.4. Handshake protocol ...................................57
A.4.1. Hello messages .....................................57
A.4.2. Server authentication and key exchange messages ....58
A.4.3. Client authentication and key exchange messages ....59
A.4.4.Handshake finalization message ......................60
A.5. The CipherSuite ......................................60
A.6. The Security Parameters ..............................63
B. Appendix - Glossary ............................................64
C. Appendix - CipherSuite definitions .............................68
D. Appendix - Implementation Notes ................................69
D.1 Random Number Generation and Seeding ..................70
D.2 Certificates and authentication .......................70
D.3 CipherSuites ..........................................70
E. Appendix - Backward Compatibility With SSL .....................71
E.1. Version 2 client hello ...............................72
E.2. Avoiding man-in-the-middle version rollback ..........74
F. Appendix - Security analysis ...................................74
F.1. Handshake protocol ...................................74
F.1.1. Authentication and key exchange ....................74
F.1.1.1. Anonymous key exchange ...........................75
F.1.1.2. RSA key exchange and authentication ..............75
F.1.1.3. Diffie-Hellman key exchange with authentication ..76
F.1.2. Version rollback attacks ...........................77
F.1.3. Detecting attacks against the handshake protocol ...77
F.1.4. Resuming sessions ..................................78
F.1.5. MD5 and SHA ........................................78
F.2. Protecting application data ..........................78
F.3. Explicit IVs .........................................79
F.4 Security of Composite Cipher Modes ...................79
F.5 Denial of Service ....................................80
F.6. Final notes ..........................................80
Normative References ..............................................81
Informative References ............................................82
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., DES [DES], 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.
- 连接是私有的。对称加密用于数据加密（例如DES[DES]、RC4[SCH]等）。此对称加密的密钥为每个连接唯一生成，并且基于另一协议（如TLS握手协议）协商的秘密。记录协议也可以在不加密的情况下使用。
- The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, 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、MD5等）用于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], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers.
- 对等方的身份可以使用非对称或公钥加密（例如RSA[RSA]、DSS[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
TLS的一个优点是它独立于应用程序协议。更高级别的协议可以在TLS协议之上分层
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之上运行的协议的设计者和实现者来判断。
This document is a revision of the TLS 1.0 [TLS1.0] protocol, and contains some small security improvements, clarifications, and editorial improvements. The major changes are:
本文档是TLS 1.0[TLS1.0]协议的修订版，包含一些小的安全改进、澄清和编辑改进。主要的变化是：
- The implicit Initialization Vector (IV) is replaced with an explicit IV to protect against CBC attacks [CBCATT].
- 隐式初始化向量（IV）替换为显式IV，以防止CBC攻击[CBCATT]。
- Handling of padding errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
- 填充错误的处理已更改为使用bad_record_mac警报，而不是解密失败警报，以防止CBC攻击。
- IANA registries are defined for protocol parameters.
- IANA注册表是为协议参数定义的。
- Premature closes no longer cause a session to be nonresumable.
- 过早关闭不再导致会话不可恢复。
- Additional informational notes were added for various new attacks on TLS.
- 针对TLS上的各种新攻击添加了其他信息说明。
In addition, a number of minor clarifications and editorial improvements were made.
此外，还作了一些小的澄清和编辑上的改进。
In this document, the keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" are to be interpreted as described in RFC 2119 [REQ].
在本文件中，关键字“必须”、“不得”、“必需”、“应该”、“不应该”和“可能”的解释如RFC 2119[REQ]所述。
The goals of TLS Protocol, in order of their priority, are as follows:
按照协议的优先顺序，其目标如下：
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 TLS 1.1, TLS 1.0, and SSL 3.0 do not interoperate (although each protocol incorporates a mechanism by which an implementation can back down 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 1.1、TLS 1.0和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 bytestream, a multi-byte item (a numeric in the example) is formed (using C notation) by:
明确指定了所有数据项的表示形式。基本数据块大小为一个字节（即8位）。多字节数据项是从左到右、从上到下的字节串联。从ByTestStream中，多字节项（示例中为数字）通过以下方式形成（使用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
可变长度向量是通过指定合法长度的子范围来定义的，包括使用符号<floor..天花>。什么时候
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.
这些是编码的，实际长度在字节流中向量的内容之前。长度将以一个数字的形式出现，该数字消耗的字节数与保持向量指定的最大（上限）长度所需的字节数相同。实际长度字段为零的可变长度向量称为空向量。
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, 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 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).
在下面的示例中，强制是一个必须包含300到400字节类型不透明的向量。它永远不会是空的。实际长度字段消耗两个字节，一个uint16，足以表示值400（参见第4.4节）。另一方面，longer可以表示多达800字节的数据或400个uint16元素，并且它可能是空的。它的编码将包括一个在向量前面的两字节实际长度字段。编码向量的长度必须是单个元素长度的偶数倍（例如，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" or "big-endian" order; the uint32 represented by the hex bytes 01 02 03 04 is equivalent to the decimal value 16909060.
规范中的所有值都以“网络”或“大端”顺序存储；十六进制字节01 02 03 04表示的uint32相当于十进制值16909060。
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;
Enumerateds occupy 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. 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.
定义的结构可能具有基于环境中可用的某些知识的变体。选择器必须是定义结构定义的可能变量的枚举类型。select中声明的枚举的每个元素都必须有一个大小写臂。变体结构的主体可提供一个标签以供参考。表示语言没有规定在运行时选择变体的机制。
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1;
case e2: Te2;
....
case en: Ten;
} [[fv]];
} [[Tv]];
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1;
case e2: Te2;
....
case en: Ten;
} [[fv]];
} [[Tv]];
For example:
例如：
enum { apple, orange } VariantTag;
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;
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: V2; /* VariantBody, tag = orange */
} variant_body; /* optional label on variant */
} VariantRecord;
enum { apple, orange } VariantTag;
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;
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: V2; /* VariantBody, tag = orange */
} variant_body; /* optional label on variant */
} VariantRecord;
Variant structures may be qualified (narrowed) by specifying a value for the selector prior to the type. For example, an
通过在类型之前为选择器指定一个值，可以限定（缩小）变体结构。例如，一个
orange VariantRecord
桔黄色条纹
is a narrowed type of a VariantRecord containing a variant_body of type V2.
是一种变型记录的窄型，包含V2型变型体。
The four cryptographic operations digital signing, stream cipher encryption, block cipher encryption, and public key encryption are designated digitally-signed, stream-ciphered, block-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).
数字签名、流密码加密、分组密码加密和公钥加密这四种加密操作分别指定为数字签名、流密码、分组密码和公钥加密。字段的加密处理是通过在字段的类型规范之前添加适当的关键字指定来指定的。加密密钥由当前会话状态暗示（参见第6.1节）。
In digital signing, one-way hash functions are used as input for a signing algorithm. A digitally-signed element is encoded as an opaque vector <0..2^16-1>, where the length is specified by the signing algorithm and key.
在数字签名中，单向散列函数用作签名算法的输入。数字签名元素被编码为不透明向量<0..2^16-1>，其中长度由签名算法和密钥指定。
In RSA signing, a 36-byte structure of two hashes (one SHA and one MD5) is signed (encrypted with the private key). It is encoded with PKCS #1 block type 1, as described in [PKCS1A].
在RSA签名中，对两个哈希（一个SHA和一个MD5）组成的36字节结构进行签名（用私钥加密）。如[PKCS1A]所述，它使用PKCS#1块类型1编码。
Note: The standard reference for PKCS#1 is now RFC 3447 [PKCS1B]. However, to minimize differences with TLS 1.0 text, we are using the terminology of RFC 2313 [PKCS1A].
注：PKCS#1的标准参考现在是RFC 3447[PKCS1B]。然而，为了尽量减少与TLS 1.0文本的差异，我们使用RFC 2313[PKCS1A]的术语。
In DSS, the 20 bytes of the SHA hash are run directly through the Digital Signing Algorithm with no additional hashing. This produces two values, r and s. The DSS signature is an opaque vector, as above, the contents of which are the DER encoding of:
在DSS中，SHA散列的20个字节直接通过数字签名算法运行，无需额外的散列。这将产生两个值r和s。DSS签名是一个不透明的向量，如上所述，其内容为DER编码：
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
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 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 signing algorithm and key.
在公钥加密中，使用公钥算法对数据进行加密，使其只能用匹配的私钥解密。公钥加密元素被编码为不透明向量<0..2^16-1>，其中长度由签名算法和密钥指定。
An RSA-encrypted value is encoded with PKCS #1 block type 2, as described in [PKCS1A].
RSA加密值使用PKCS#1块类型2进行编码，如[PKCS1A]中所述。
In the following example,
在下面的示例中，
stream-ciphered struct {
uint8 field1;
uint8 field2;
digitally-signed opaque hash[20];
} UserType;
stream-ciphered struct {
uint8 field1;
uint8 field2;
digitally-signed opaque hash[20];
} UserType;
the contents of hash are used as input for the signing 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 length of the signature, plus the length of the output of the signing algorithm. This is known because the algorithm and key used for the signing are known prior to encoding or decoding this structure.
哈希的内容用作签名算法的输入，然后使用流密码对整个结构进行加密。此结构的长度（以字节为单位）将等于field1和field2的两个字节，再加上签名长度的两个字节，再加上签名算法输出的长度。这是已知的，因为用于签名的算法和密钥在编码或解码该结构之前是已知的。
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 */
A number of operations in the TLS record and handshake layer require a keyed MAC; this is a secure digest of some data protected by a secret. Forging the MAC is infeasible without knowledge of the MAC secret. The construction we use for this operation is known as HMAC, and is described in [HMAC].
TLS记录和握手层中的许多操作需要密钥MAC；这是受机密保护的某些数据的安全摘要。如果不知道MAC的秘密，伪造MAC是不可行的。我们用于此操作的结构称为HMAC，并在[HMAC]中进行了描述。
HMAC can be used with a variety of different hash algorithms. TLS uses it in the handshake with two different algorithms, MD5 and SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, data). Additional hash algorithms can be defined by cipher suites
HMAC可以与各种不同的哈希算法一起使用。TLS使用MD5和SHA-1两种不同的算法在握手中使用它，将它们表示为HMAC_MD5（机密，数据）和HMAC_SHA（机密，数据）。其他哈希算法可以由密码套件定义
and used to protect record data, but MD5 and SHA-1 are hard coded into the description of the handshaking for this version of the protocol.
和用于保护记录数据，但MD5和SHA-1硬编码到该版本协议的握手描述中。
In addition, a construction is required to do expansion of secrets into blocks of data for the purposes of key generation or validation. This pseudo-random function (PRF) takes as input a secret, a seed, and an identifying label and produces an output of arbitrary length.
此外，为了密钥生成或验证的目的，需要一个构造来将秘密扩展到数据块中。这个伪随机函数（PRF）以一个秘密、一个种子和一个识别标签作为输入，并产生任意长度的输出。
In order to make the PRF as secure as possible, it uses two hash algorithms in a way that should guarantee its security if either algorithm remains secure.
为了使PRF尽可能安全，它使用了两种哈希算法，如果其中一种算法保持安全，则应保证其安全性。
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 is necessary to produce the required quantity of data. For example, if P_SHA-1 is being used to create 64 bytes of data, it will have to be iterated 4 times (through A(4)), creating 80 bytes of output data; the last 16 bytes of the final iteration will then be discarded, leaving 64 bytes of output data.
P_散列可以根据需要多次迭代以生成所需数量的数据。例如，如果P_SHA-1用于创建64字节的数据，则必须迭代4次（通过A（4）），从而创建80字节的输出数据；最终迭代的最后16个字节将被丢弃，留下64个字节的输出数据。
TLS's PRF is created by splitting the secret into two halves and using one half to generate data with P_MD5 and the other half to generate data with P_SHA-1, then exclusive-ORing the outputs of these two expansion functions together.
TLS的PRF是通过将机密分为两半，使用一半与P_MD5生成数据，另一半与P_SHA-1生成数据，然后对这两个扩展函数的输出进行异或运算来创建的。
S1 and S2 are the two halves of the secret, and each is the same length. S1 is taken from the first half of the secret, S2 from the second half. Their length is created by rounding up the length of the overall secret, divided by two; thus, if the original secret is an odd number of bytes long, the last byte of S1 will be the same as the first byte of S2.
S1和S2是秘密的两部分，每部分长度相同。S1取自《秘密》的前半部分，S2取自《秘密》的后半部分。它们的长度是通过将整个秘密的长度四舍五入除以二而产生的；因此，如果原始机密是奇数字节长，则S1的最后一个字节将与S2的第一个字节相同。
L_S = length in bytes of secret;
L_S1 = L_S2 = ceil(L_S / 2);
L_S = length in bytes of secret;
L_S1 = L_S2 = ceil(L_S / 2);
The secret is partitioned into two halves (with the possibility of one shared byte) as described above, S1 taking the first L_S1 bytes, and S2 the last L_S2 bytes.
如上所述，秘密被分成两半（可能有一个共享字节），S1取第一个L_S1字节，S2取最后一个L_S2字节。
The PRF is then defined as the result of mixing the two pseudorandom streams by exclusive-ORing them together.
然后，PRF被定义为通过将两个伪随机流排他或组合在一起来混合它们的结果。
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
P_SHA-1(S2, label + seed);
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
P_SHA-1(S2, 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
Note that because MD5 produces 16-byte outputs and SHA-1 produces 20-byte outputs, the boundaries of their internal iterations will not be aligned. Generating an 80-byte output will require that P_MD5 iterate through A(5), while P_SHA-1 will only iterate through A(4).
注意，因为MD5产生16字节的输出，而SHA-1产生20字节的输出，所以它们内部迭代的边界将不会对齐。生成一个80字节的输出将需要P_MD5迭代A（5），而P_SHA-1将只迭代A（4）。
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 record protocol clients 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 types can be supported by the record protocol. Any new record types SHOULD allocate type values immediately beyond the ContentType values for the four record types described here (see Appendix A.1). All such values must be defined by RFC 2434 Standards Action. See Section 11 for IANA Considerations for ContentType values.
本文描述了四种记录协议客户端：握手协议、警报协议、更改密码规范协议和应用程序数据协议。为了允许TLS协议的扩展，记录协议可以支持其他记录类型。任何新的记录类型都应为此处描述的四种记录类型分配超出ContentType值的类型值（见附录A.1）。所有此类值必须由RFC 2434标准行动定义。有关ContentType值的IANA注意事项，请参见第11节。
If a TLS implementation receives a record type it does not understand, it SHOULD just ignore it. Any protocol designed for use
如果TLS实现接收到它不理解的记录类型，它应该忽略它。为使用而设计的任何协议
over TLS MUST be carefully designed to deal with all possible attacks against it. Note that because the type and length of a record are not protected by encryption, care SHOULD be taken to minimize the value of traffic analysis of these values.
必须仔细设计over TLS，以应对所有可能的攻击。请注意，由于记录的类型和长度不受加密保护，因此应注意最小化这些值的流量分析值。
A TLS connection state is the operating environment of the TLS Record Protocol. It specifies a compression algorithm, and encryption algorithm, and a MAC algorithm. In addition, the parameters for these algorithms are known: the MAC secret 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 Change Cipher Spec 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握手协议设置，并且变更密码规范可以选择性地使任一待决状态成为当前状态，在这种情况下，适当的当前状态被处理并替换为待决状态；然后将挂起状态重新初始化为空状态。将未使用安全参数初始化的状态设置为当前状态是非法的。初始当前状态始终指定不使用加密、压缩或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.
连接结束此实体在此连接中被视为“客户端”还是“服务器”。
bulk encryption algorithm An algorithm to be used for bulk encryption. This specification includes the key size of this algorithm, how much of that key is secret, whether it is a block or stream cipher, and the block size of the cipher (if appropriate).
批量加密算法用于批量加密的算法。该规范包括该算法的密钥大小、该密钥的保密程度、是块密码还是流密码以及密码的块大小（如果合适）。
MAC algorithm An algorithm to be used for message authentication. This specification includes the size of the hash 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 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 { null, rc4, rc2, des, 3des, des40, idea, aes }
BulkCipherAlgorithm;
enum { null, rc4, rc2, des, 3des, des40, idea, aes }
BulkCipherAlgorithm;
enum { stream, block } CipherType;
enum { stream, block } CipherType;
enum { null, md5, sha } MACAlgorithm;
enum { null, md5, sha } MACAlgorithm;
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
/* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
/* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct {
ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct {
ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
MACAlgorithm mac_algorithm;
uint8 hash_size;
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 four items:
记录层将使用安全参数生成以下四项：
client write MAC secret server write MAC secret client write key server write key
客户端写入MAC密钥服务器写入MAC密钥客户端写入密钥服务器写入密钥
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 secret The MAC secret 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, minor;
} ProtocolVersion;
struct {
uint8 major, 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.1, which uses the version { 3, 2 }. The version value 3.2 is historical: TLS version 1.1 is a minor modification to the TLS 1.0 protocol, which was itself a minor modification to the SSL 3.0 protocol, which bears the version value 3.0. (See Appendix A.1.)
版本正在使用的协议的版本。本文档描述了TLS版本1.1，它使用版本{3,2}。版本值3.2是历史版本：TLS版本1.1是对TLS 1.0协议的一次小修改，它本身是对SSL 3.0协议的一次小修改，该协议具有版本值3.0。（见附录A.1。）
length The length (in bytes) of the following TLSPlaintext.fragment. The length should not exceed 2^14.
length以下TLSPlaintext.fragment的长度（以字节为单位）。长度不应超过2^14。
fragment The application data. This data is transparent and is treated as an independent block to be dealt with by the higher-level protocol specified by the type field.
分割应用程序数据。该数据是透明的，并被视为一个独立的块，由类型字段指定的高级协议处理。
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.
使用当前会话状态中定义的压缩算法压缩所有记录。总是有一个主动的压缩算法；但是，最初它被定义为CompressionMethod.null。压缩算法将TLSPlaintText结构转换为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 should 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 should 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 (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} 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 may 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[CipherSpec.hash_size];
} GenericStreamCipher;
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
The MAC is generated as:
MAC生成为：
HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length +
TLSCompressed.fragment));
HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length +
TLSCompressed.fragment));
where "+" denotes concatenation.
其中“+”表示串联。
seq_num The sequence number for this record.
seq_num此记录的序列号。
hash The hashing algorithm specified by SecurityParameters.mac_algorithm.
哈希SecurityParameters.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 CipherSuite 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). TLSCiphertext.length is TLSCompressed.length plus CipherSpec.hash_size.
在计算MAC之前的加密注释。流密码加密整个块，包括MAC。对于不使用同步向量（如RC4）的流密码，一条记录末尾的流密码状态仅用于后续数据包。如果密码套件为TLS_NULL_WITH_NULL_NULL，则加密由标识操作组成（即数据未加密，MAC大小为零，表示未使用MAC）。TLSCiphertext.length是TLSCompressed.length加上CipherSpec.hash_大小。
For block ciphers (such as RC2, DES, or AES), the encryption and MAC functions convert TLSCompressed.fragment structures to and from block TLSCiphertext.fragment structures.
对于块密码（如RC2、DES或AES），加密和MAC函数将TLSCompressed.fragment结构与块TLSCiphertext.fragment结构进行转换。
block-ciphered struct {
opaque IV[CipherSpec.block_length];
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
block-ciphered struct {
opaque IV[CipherSpec.block_length];
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
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 Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit IV in order to prevent the attacks described by [CBCATT]. We recommend the following equivalently strong procedures. For clarity we use the following notation.
IV与以前版本的SSL和TLS不同，TLS 1.1使用显式IV以防止[CBCATT]描述的攻击。我们建议采用以下同等强大的程序。为清楚起见，我们使用以下符号。
IV The transmitted value of the IV field in the GenericBlockCipher structure.
IV通用分组密码结构中IV字段的传输值。
CBC residue The last ciphertext block of the previous record.
CBC剩余：上一条记录的最后一个密文块。
mask The actual value that the cipher XORs with the plaintext prior to encryption of the first cipher block of the record.
在加密记录的第一个密码块之前，用明文屏蔽密码XOR的实际值。
In prior versions of TLS, there was no IV field and the CBC residue and mask were one and the same. See Sections 6.1, 6.2.3.2, and 6.3, of [TLS1.0] for details of TLS 1.0 IV handling.
在先前版本的TLS中，没有IV字段，CBC残留物和面罩是相同的。参见[TLS1.0]第6.1节、第6.2.3.2节和第6.3节，了解TLS1.0 IV处理的详细信息。
One of the following two algorithms SHOULD be used to generate the per-record IV:
应使用以下两种算法之一生成每记录IV：
(1) Generate a cryptographically strong random string R of length CipherSpec.block_length. Place R in the IV field. Set the mask to R. Thus, the first cipher block will be encrypted as E(R XOR Data).
(1) 生成长度为CipherSpec.block_的加密强随机字符串R。将R放置在IV字段中。将掩码设置为R。因此，第一个密码块将被加密为E（R XOR数据）。
(2) Generate a cryptographically strong random number R of length CipherSpec.block_length and prepend it to the plaintext prior to encryption. In this case either:
(2) 生成一个长度为CipherSpec.block_长度的加密强随机数R，并在加密之前将其预编为明文。在这种情况下：
(a) The cipher may use a fixed mask such as zero. (b) The CBC residue from the previous record may be used as the mask. This preserves maximum code compatibility with TLS 1.0 and SSL 3. It also has the advantage that it does not require the ability to quickly reset the IV, which is known to be a problem on some systems.
(a) 密码可以使用固定的掩码，例如零。（b） 先前记录中的CBC残留物可用作遮罩。这保留了与TLS 1.0和SSL 3的最大代码兼容性。它还有一个优点，即不需要快速重置IV，这在某些系统上是一个问题。
In either (2)(a) or (2)(b) the data (R || data) is fed into the encryption process. The first cipher block (containing E(mask XOR R) is placed in the IV field. The first block of content contains E(IV XOR data).
在（2）（a）或（2）（b）中，数据（R | | data）被送入加密过程。第一个密码块（包含E（掩码异或）放在IV字段中。第一个内容块包含E（IV异或数据）。
The following alternative procedure MAY be used; however, it has not been demonstrated to be as cryptographically strong as the above procedures. The sender prepends a fixed block F to the plaintext (or, alternatively, a block generated with a weak PRNG). He then encrypts as in (2), above, using the CBC residue from the previous block as the mask for the prepended block. Note that in this case the mask for the first record transmitted by the application (the Finished) MUST be generated using a cryptographically strong PRNG.
可采用以下替代程序：；然而，它还没有被证明具有上述程序那样强大的加密能力。发送方将固定块F前置到明文（或者，用弱PRNG生成的块）。然后，他使用前一块中的CBC残留物作为预加块的掩码，按照上面（2）中的方式进行加密。请注意，在这种情况下，应用程序传输的第一条记录（完成记录）的掩码必须使用加密强PRNG生成。
The decryption operation for all three alternatives is the same. The receiver decrypts the entire GenericBlockCipher structure and then discards the first cipher block, corresponding to the IV component.
所有三个备选方案的解密操作都是相同的。接收器解密整个GenericBlockCipher结构，然后丢弃对应于IV分量的第一个密码块。
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
填充添加的填充，用于强制明文长度为分组密码的块长度的整数倍。填充可以是最大255字节的任何长度，只要它导致TLSCiphertext.length是块长度的整数倍。对于基于交换消息长度分析的协议，可能需要更长的长度来阻止攻击。填充数据向量中的每个uint8必须用填充长度值填充。接受者
MUST check this padding and SHOULD use the bad_record_mac alert to indicate padding errors.
必须检查此填充，并应使用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 CipherSpec.block_length, TLSCompressed.length, CipherSpec.hash_size, and padding_length.
加密数据长度（TLSCiphertext.length）比CipherSpec.block_长度、TLSCompressed.length、CipherSpec.hash_大小和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 IV, which may or may not be encrypted, as discussed above). 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字节，内容长度（TLSCompressed.length）为61字节，MAC长度为20字节，则填充前的长度为82字节（这不包括IV，如上所述，IV可能被加密，也可能未被加密）。因此，为了使总长度为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,
实现说明：Canvel等人[CBCTIME]已经证明了基于计算MAC所需时间对CBC填充的定时攻击。为了抵御这种攻击，实现必须确保无论填充是否正确，记录处理时间基本相同。一般来说，最好的方法是计算MAC，即使填充不正确，然后才拒绝数据包。例如，如果pad看起来不正确，那么实现可能会假设一个零长度的pad，然后计算MAC。这留下了一个小的定时通道，因为MAC性能在某种程度上取决于数据片段的大小，
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.
但是，由于现有mac的大数据块大小和定时信号的小尺寸，人们认为它不够大，无法利用。
The Record Protocol requires an algorithm to generate keys, and MAC secrets from the security parameters provided by the handshake protocol.
记录协议需要一种算法来根据握手协议提供的安全参数生成密钥和MAC机密。
The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets and keys required by the current connection state (see Appendix A.6). CipherSpecs require a client write MAC secret, a server write MAC secret, a client write key, and a server write key, each of which is generated from the master secret in that order. Unused values are empty.
主密钥散列为一系列安全字节，这些字节分配给当前连接状态所需的MAC密钥和密钥（见附录a.6）。CipherSpec需要一个客户端写MAC密钥、一个服务器写MAC密钥、一个客户端写密钥和一个服务器写密钥，每个密钥都是按照主密钥的顺序生成的。未使用的值为空。
When keys and MAC secrets 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_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
Implementation note: The currently defined cipher suite that requires the most material is AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x 32 byte keys, 2 x 20 byte MAC secrets, and 2 x 16 byte Initialization Vectors, for a total of 136 bytes of key material.
实施说明：目前定义的需要最多材料的密码套件是[TLSAES]中定义的AES_256_CBC_SHA。它需要2 x 32字节的密钥、2 x 20字节的MAC机密和2 x 16字节的初始化向量，总共需要136字节的密钥材料。
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 [X509] certificate of the peer. This element of the state may be null.
对等方证书X509v3[X509]对等方的证书。状态的此元素可能为null。
compression method The algorithm used to compress data prior to encryption.
压缩方法加密前用于压缩数据的算法。
cipher spec Specifies the bulk data encryption algorithm (such as null, DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also defines cryptographic attributes such as the hash_size. (See Appendix A.6 for formal definition.)
cipher spec指定批量数据加密算法（如null、DES等）和MAC算法（如MD5或SHA）。它还定义加密属性，如哈希值大小。（正式定义见附录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 change cipher spec 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. (See Section 6.1.) The change cipher spec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying finished message is sent (see Section 7.4.9).
发送此消息后，发送方必须立即指示记录层将写挂起状态设置为写活动状态。（见第6.1节。）更改密码规范消息在安全参数商定后的握手过程中发送，但在发送验证完成消息之前发送（见第7.4.9节）。
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 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(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),
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(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), (255) } AlertDescription;
拒绝访问（49）、解码错误（50）、解密错误（51）、保留导出限制（60）、协议版本（70）、安全性不足（71）、内部错误（80）、用户取消（90）、无重新协商（100）、（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
如果使用TLS的应用程序协议规定，在TLS连接关闭后，任何数据都可能通过底层传输传输，则TLS实现必须在向应用程序层指示TLS连接已结束之前接收响应的close_notify警报。如果应用程序协议不会传输任何附加数据，而只会关闭底层传输连接，则实现可以选择关闭
transport without waiting for the responding close_notify. No part of this standard should be taken to dictate the manner in which a usage profile for TLS manages its data transport, including when connections are opened or closed.
在不等待响应关闭通知的情况下进行传输。本标准的任何部分都不应规定TLS使用概要文件管理其数据传输的方式，包括连接打开或关闭时的方式。
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. The following error alerts are defined:
TLS握手协议中的错误处理非常简单。当检测到错误时，检测方向另一方发送消息。在传输或接收到致命警报消息后，双方立即关闭连接。服务器和客户端必须忘记与失败连接相关的任何会话标识符、密钥和机密。因此，任何以致命警报终止的连接都不能恢复。定义了以下错误警报：
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.
错误\u记录\u mac如果接收到带有错误mac的记录，将返回此警报。如果发送警报的原因是TLSCiphertext以无效方式解密：它不是块长度的偶数倍，或者其填充值（选中时）不正确，则也必须返回此警报。这个消息总是致命的。
decryption_failed This alert MAY be returned if 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.
解密失败如果TLSCiphertext以无效方式解密，则可能会返回此警报：它不是块长度的偶数倍，或者其填充值在选中时不正确。这个消息总是致命的。
Note: Differentiating between bad_record_mac and decryption_failed alerts may permit certain attacks against CBC mode as used in TLS [CBCATT]. It is preferable to uniformly use the bad_record_mac alert to hide the specific type of the error.
注意：区分坏记录和解密失败警报可能会允许对TLS[CBCATT]中使用的CBC模式进行某些攻击。最好统一使用坏记录mac警报来隐藏特定类型的错误。
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.
记录溢出收到长度超过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.
解压失败解压功能接收到不正确的输入（例如，数据会扩展到过长）。这个消息总是致命的。
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 in TLS. It should 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 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.
解码\错误无法解码消息，因为某些字段超出指定范围或消息长度不正确。这个消息总是致命的。
decrypt_error A handshake cryptographic operation failed, including being unable to correctly verify a signature, decrypt a key exchange, or validate a finished message.
解密错误握手加密操作失败，包括无法正确验证签名、解密密钥交换或验证完成的消息。
export_restriction_RESERVED This alert was used in TLS 1.0 but not TLS 1.1.
导出\u限制\u保留此警报已在TLS 1.0中使用，但未在TLS 1.1中使用。
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
初始握手后，客户端响应hello请求或服务器响应客户端hello时不发送重新协商。其中任何一项通常都会导致重新谈判；当这不合适时，收件人应回复此警报。此时，原始请求者可以决定是否继续连接。一种适当的情况是，服务器产生了一个进程来满足请求；进程在启动时可能会收到安全参数（密钥长度、身份验证等），并且
might be difficult to communicate changes to these parameters after that point. This message is always a warning.
在此之后，可能很难传达对这些参数的更改。此消息始终是一个警告。
For all errors where an alert level is not explicitly specified, the sending party MAY determine at its discretion whether this is a fatal error or not; if an alert with a level of warning is received, the receiving party MAY decide at its discretion whether to treat this as a fatal error or not. However, all messages that are transmitted with a level of fatal MUST be treated as fatal messages.
对于未明确规定警报级别的所有错误，发送方可自行决定这是否为致命错误；如果收到警告级别的警报，接收方可自行决定是否将其视为致命错误。但是，以致命级别传输的所有消息必须视为致命消息。
New alert values MUST be defined by RFC 2434 Standards Action. See Section 11 for IANA Considerations for alert values.
新警报值必须由RFC 2434标准操作定义。有关警报值的IANA注意事项，请参见第11节。
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
请注意，更高层不应过度依赖TLS是否始终协商两个对等方之间可能最强的连接。中间人攻击者可以通过多种方式试图使两个实体下降到它们支持的最不安全的方法。该协议旨在将此风险降至最低，但仍然存在可用的攻击。对于
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协议是安全的，因为任何密码套件都提供其承诺的安全级别：如果您与已验证其证书的主机协商使用1024位RSA密钥交换的3DE，那么您可以期望是安全的。
However, one SHOULD never send data over a link encrypted with 40-bit security unless one feels that data is worth no more than the effort required to break that encryption.
然而，人们永远不应该通过40位安全加密的链接发送数据，除非人们认为数据的价值不超过破坏加密所需的努力。
These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a client hello message to which the server must respond with a server hello message, or else a fatal error will occur and the connection will fail. The client hello and server hello are used to establish security enhancement capabilities between client and server. The client hello and server hello 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.
这些目标是通过握手协议实现的，握手协议可以概括如下：客户端发送客户端hello消息，服务器必须用服务器hello消息响应该消息，否则将发生致命错误，连接将失败。客户端hello和服务器hello用于在客户端和服务器之间建立安全增强功能。客户端hello和服务器hello建立以下属性：协议版本、会话ID、密码套件和压缩方法。此外，还会生成并交换两个随机值：ClientHello.random和ServerHello.random。
The actual key exchange uses up to four messages: the server certificate, the server key exchange, the client certificate, and the client key exchange. 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 48 to 128 bytes in length.
实际的密钥交换最多使用四条消息：服务器证书、服务器密钥交换、客户端证书和客户端密钥交换。新的密钥交换方法可以通过为这些消息指定格式和定义消息的使用来创建，以允许客户端和服务器就共享秘密达成一致。这个秘密一定很长；当前定义的密钥交换方法交换长度为48到128字节的秘密。
Following the hello messages, the server will send its certificate, if it is to be authenticated. Additionally, a server key exchange 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 server hello done 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 certificate request message, the client must send the certificate message. The client key exchange message is now sent, and the content of that message will depend on the public key algorithm selected between the client hello and the server hello. If the client has sent a certificate with signing ability, a digitally-
在hello消息之后，服务器将发送其证书（如果要对其进行身份验证）。此外，如果需要，可以发送服务器密钥交换消息（例如，如果服务器没有证书，或者如果其证书仅用于签名）。如果服务器经过身份验证，它可能会从客户端请求证书（如果该证书适用于所选的密码套件）。接下来，服务器将发送服务器hello done消息，指示握手的hello消息阶段已完成。然后，服务器将等待客户端响应。如果服务器已发送证书请求消息，则客户端必须发送证书消息。现在发送客户机密钥交换消息，该消息的内容将取决于在客户机hello和服务器hello之间选择的公钥算法。如果客户端已发送具有签名功能的证书，则-
signed certificate verify message is sent to explicitly verify the certificate.
发送签名证书验证消息以显式验证证书。
At this point, a change cipher spec 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 change cipher spec 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 TLS_NULL_WITH_NULL_NULL is established).
此时，客户机将发送更改密码规范消息，并将挂起的密码规范复制到当前密码规范中。然后，客户机立即根据新算法、密钥和机密发送完成的消息。作为响应，服务器将发送其自己的更改密码规范消息，将挂起的密码规范传输到当前密码规范，并根据新密码规范发送其完成的消息。此时，握手完成，客户端和服务器可以开始交换应用层数据。（参见下面的流程图。）在第一次握手完成之前（在建立密码套件之前，其他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
Fig. 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.
客户端使用要恢复的会话的会话ID发送ClientHello。然后服务器检查其会话缓存是否匹配。
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 change cipher spec 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值的ServerHello。此时，客户端和服务器都必须发送更改密码规范消息，并直接处理完成的消息。一旦重建完成，客户端和服务器就可以开始交换应用层数据。（请参阅下面的流程图。）如果找不到会话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
Fig. 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;
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;
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 is described only in its first position. The one message that is not bound by these ordering rules is the Hello Request 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.
握手协议消息按其必须发送的顺序显示在下面；以意外顺序发送握手消息会导致致命错误。然而，不需要的握手信息可以省略。注意排序的一个例外：证书消息在握手中使用了两次（从服务器到客户端，然后从客户端到服务器），但仅在第一个位置进行描述。不受这些排序规则约束的一个消息是hello请求消息，该消息可以在任何时候发送，但如果客户端在握手期间到达，则应该忽略该消息。
New Handshake message type values MUST be defined via RFC 2434 Standards Action. See Section 11 for IANA Considerations for these values.
必须通过RFC 2434标准操作定义新的握手消息类型值。有关这些值的IANA注意事项，请参见第11节。
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 hello request message MAY be sent by the server at any time.
hello请求消息可由服务器随时发送。
Meaning of this message:
此信息的含义：
Hello request is a simple notification that the client should begin the negotiation process anew by sending a client hello message when convenient. 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
Hello请求是一个简单的通知，客户机应该在方便的时候通过发送客户机Hello消息重新开始协商过程。如果客户端当前正在协商会话，则客户端将忽略此消息。如果客户端不希望重新协商会话，则可以忽略此消息；如果客户端愿意，则可以响应此消息
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 hello request but does not receive a client hello in response, it may close the connection with a fatal alert.
没有重新协商警报。由于握手消息的传输优先于应用程序数据，因此在从客户端接收到不超过几个记录之前，协商将开始。如果服务器发送hello请求但未收到客户机hello响应，则可能会通过致命警报关闭连接。
After sending a hello request, servers SHOULD not repeat the request until the subsequent handshake negotiation is complete.
发送hello请求后，服务器不应重复该请求，直到后续握手协商完成。
Structure of this message:
此消息的结构：
struct { } HelloRequest;
struct { } HelloRequest;
Note: 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 client hello as its first message. The client can also send a client hello in response to a hello request or on its own initiative in order to renegotiate the security parameters in an existing connection.
当客户机首次连接到服务器时，需要将客户机hello作为其第一条消息发送。客户机还可以发送客户机hello以响应hello请求，或者主动发送，以便在现有连接中重新协商安全参数。
Structure of this message:
此消息的结构：
The client hello message includes a random structure, which is used later in the protocol.
客户机hello消息包含一个随机结构，该结构稍后将在协议中使用。
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, GMT, 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.
gmt_unix_time标准unix 32位格式的当前时间和日期（自1970年1月1日午夜开始的秒，gmt，忽略闰秒），根据发送方的内部时钟。基本TLS协议不要求正确设置时钟；更高级别的协议或应用程序协议可能会定义其他要求。
random_bytes 28 bytes generated by a secure random number generator.
随机字节由安全随机数生成器生成的28个字节。
The client hello 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, from 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.
客户机hello消息包括一个可变长度的会话标识符。如果不为空，则该值标识同一客户端和服务器之间的会话，客户端希望重用其安全参数。会话标识符可能来自早期连接、此连接或另一个当前活动连接。如果客户端只希望更新连接的随机结构和派生值，则第二个选项很有用，第三个选项可以在不重复完整握手协议的情况下建立多个独立的安全连接。这些独立的连接可以连续或同时发生；当握手协商完成并交换完成的消息时，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 CipherSuite list, passed from the client to the server in the client hello message, contains the combinations of cryptographic algorithms supported by the client in order of the client's preference (favorite choice first). Each CipherSuite defines a key exchange algorithm, a bulk encryption algorithm (including secret key length), and a MAC algorithm. The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection.
CipherSuite列表在客户机hello消息中从客户机传递到服务器，包含客户机支持的加密算法组合，按客户机的首选项顺序排列（首选项优先）。每个密码套件定义一个密钥交换算法、一个批量加密算法（包括密钥长度）和一个MAC算法。服务器将选择密码套件，如果没有可接受的选项，则返回握手失败警报并关闭连接。
uint8 CipherSuite[2]; /* Cryptographic suite selector */
uint8 CipherSuite[2]; /* Cryptographic suite selector */
The client hello includes a list of compression algorithms supported by the client, ordered according to the client's preference.
客户机hello包括客户机支持的压缩算法列表，根据客户机的偏好排序。
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-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
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.2. (See Appendix E for details about backward compatibility.)
客户端版本客户端希望在此会话期间通信的TLS协议版本。这应该是客户端支持的最新（最高值）版本。对于本规范版本，版本为3.2。（有关向后兼容性的详细信息，请参见附录E。）
random A client-generated random structure.
随机客户端生成的随机结构。
session_id The ID of a session the client wishes to use for this connection. This field should be 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这是客户机支持的加密选项列表，首先是客户机的首选项。如果会话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 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.
压缩方法这是客户机支持的压缩方法列表，按客户机首选项排序。如果session_id字段不是空的（意味着会话恢复请求），它必须包含来自该会话的compression_方法。此向量必须包含并且所有实现都必须支持CompressionMethod.null。因此，客户机和服务器始终能够就压缩方法达成一致。
After sending the client hello message, the client waits for a server hello message. Any other handshake message returned by the server except for a hello request is treated as a fatal error.
发送客户机hello消息后，客户机等待服务器hello消息。服务器返回的任何其他握手消息（hello请求除外）都被视为致命错误。
Forward compatibility note: In the interests of forward compatibility, it is permitted that a client hello message include extra data after the compression methods. This data MUST be included
前向兼容性注意：为了前向兼容性，允许客户端hello消息在压缩方法之后包含额外数据。必须包括这些数据
in the handshake hashes, but must otherwise be ignored. This is the only handshake message for which this is legal; for all other messages, the amount of data in the message MUST match the description of the message precisely.
在握手哈希中，但必须忽略。这是唯一合法的握手信息；对于所有其他消息，消息中的数据量必须与消息的描述精确匹配。
Note: For the intended use of trailing data in the ClientHello, see RFC 3546 [TLSEXT].
注：有关ClientHello中尾随数据的预期用途，请参阅RFC 3546[TLSEXT]。
The server will send this message in response to a client hello 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.
当服务器能够找到一组可接受的算法时，它将发送此消息以响应客户机hello消息。如果找不到这样的匹配项，它将发出握手失败警报。
Structure of this message:
此消息的结构：
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
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.2. (See Appendix E for details about backward compatibility.)
服务器版本此字段将包含客户端hello中客户端建议的较低版本和服务器支持的最高版本。对于本规范版本，版本为3.2。（有关向后兼容性的详细信息，请参见附录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.
会话\u id这是与此连接对应的会话的标识。如果ClientHello.session_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方法列表中选择的单一压缩算法。对于恢复的会话，此字段是恢复的会话状态的值。
When this message will be sent:
将发送此消息的时间：
The server MUST send a certificate whenever the agreed-upon key exchange method is not an anonymous one. This message will always immediately follow the server hello message.
只要约定的密钥交换方法不是匿名的，服务器就必须发送证书。此消息将始终紧跟在服务器hello消息之后。
Meaning of this message:
此信息的含义：
The certificate type MUST be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509v3 certificate. It MUST contain a key that matches the key exchange method, as follows. Unless otherwise specified, the signing algorithm for the certificate MUST be the same as the algorithm for the certificate key. Unless otherwise specified, the public key MAY be of any length.
证书类型必须适合所选密码套件的密钥交换算法，通常为X.509v3证书。它必须包含与密钥交换方法匹配的密钥，如下所示。除非另有规定，否则证书的签名算法必须与证书密钥的算法相同。除非另有规定，公钥可以是任意长度。
Key Exchange Algorithm Certificate Key Type
密钥交换算法证书密钥类型
RSA RSA public key; the certificate MUST allow the key to be used for encryption.
RSA公钥；证书必须允许密钥用于加密。
DHE_DSS DSS public key.
DHE_DSS DSS公钥。
DHE_RSA RSA public key that can be used for signing.
可用于签名的DHE_RSA公钥。
DH_DSS Diffie-Hellman key. The algorithm used to sign the certificate MUST be DSS.
DH_DSS Diffie Hellman密钥。用于签署证书的算法必须是DSS。
DH_RSA Diffie-Hellman key. The algorithm used to sign the certificate MUST be RSA.
DH_RSA Diffie-Hellman密钥。用于签署证书的算法必须是RSA。
All certificate profiles and key and cryptographic formats are defined by the IETF PKIX working group [PKIX]. When a key usage extension is present, the digitalSignature bit MUST be set for the key to be eligible for signing, as described above, and the keyEncipherment bit MUST be present to allow encryption, as described above. The keyAgreement bit must be set on Diffie-Hellman certificates.
所有证书配置文件以及密钥和加密格式由IETF PKIX工作组[PKIX]定义。当存在密钥使用扩展时，如上所述，必须设置数字签名位以使密钥符合签名条件，并且如上所述，必须存在密钥加密位以允许加密。必须在Diffie-Hellman证书上设置keyAgreement位。
As CipherSuites that specify new key exchange methods are specified for the TLS Protocol, they will imply certificate format and the required encoded keying information.
由于为TLS协议指定了指定新密钥交换方法的密码套件，它们将暗示证书格式和所需的编码密钥信息。
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 X.509v3 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 optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
证书列表这是X.509v3证书的序列（链）。发件人的证书必须排在列表的第一位。下列证书必须直接证明其前面的证书。由于证书验证要求独立分发根密钥，因此可以选择从链中省略指定根证书颁发机构的自签名证书，前提是远程端必须已经拥有该证书，以便在任何情况下对其进行验证。
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定义了一个集合而不是一个序列，这使得解析列表的任务更加困难。
When this message will be sent:
将发送此消息的时间：
This message will be sent immediately after the server certificate message (or the server hello message, if this is an anonymous negotiation).
此消息将在服务器证书消息（或服务器hello消息，如果这是匿名协商）之后立即发送。
The server key exchange 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机密时由服务器发送。这适用于以下密钥交换方法：
DHE_DSS DHE_RSA DH_anon
DHE_DSS DHE_RSA DH_anon
It is not legal to send the server key exchange message for the following key exchange methods:
为以下密钥交换方法发送服务器密钥交换消息是不合法的：
RSA DH_DSS DH_RSA
RSA DH_DSS DH_RSA
Meaning of this message:
此信息的含义：
This message conveys cryptographic information to allow the client to communicate the premaster secret: either an RSA public key with which to encrypt the premaster secret, or a Diffie-Hellman public key with which the client can complete a key exchange (with the result being the premaster secret).
此消息传递加密信息以允许客户端通信premaster机密：用于加密premaster机密的RSA公钥，或用于客户端完成密钥交换（结果为premaster机密）的Diffie-Hellman公钥。
As additional CipherSuites 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定义了其他密码套件，因此只有当且仅当与密钥交换算法关联的证书类型没有为客户端提供足够的信息来交换premaster机密时，才会发送服务器密钥交换消息。
Structure of this message:
此消息的结构：
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct {
opaque rsa_modulus<1..2^16-1>;
opaque rsa_exponent<1..2^16-1>;
} ServerRSAParams;
struct {
opaque rsa_modulus<1..2^16-1>;
opaque rsa_exponent<1..2^16-1>;
} ServerRSAParams;
rsa_modulus The modulus of the server's temporary RSA key.
rsa_module服务器临时rsa密钥的模数。
rsa_exponent The public exponent of the server's temporary RSA key.
rsa_指数服务器临时rsa密钥的公共指数。
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 diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
case rsa:
ServerRSAParams params;
};
} ServerParams;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
case rsa:
ServerRSAParams params;
};
} ServerParams;
params The server's key exchange parameters.
params服务器的密钥交换参数。
signed_params For non-anonymous key exchanges, a hash of the corresponding params value, with the signature appropriate to that hash applied.
非匿名密钥交换的签名参数，对应参数值的散列，并应用与该散列相应的签名。
md5_hash
MD5(ClientHello.random + ServerHello.random + ServerParams);
md5_hash
MD5(ClientHello.random + ServerHello.random + ServerParams);
sha_hash
SHA(ClientHello.random + ServerHello.random + ServerParams);
sha_hash
SHA(ClientHello.random + ServerHello.random + ServerParams);
enum { anonymous, rsa, dsa } SignatureAlgorithm;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
When this message will be sent:
将发送此消息的时间：
A non-anonymous server can optionally request a certificate from the client, if it is appropriate for the selected cipher suite.
如果适用于所选密码套件，非匿名服务器可以选择从客户端请求证书。
This message, if sent, will immediately follow the Server Key Exchange message (if it is sent; otherwise, the Server Certificate message).
此消息如果已发送，将立即跟随服务器密钥交换消息（如果已发送，则跟随服务器证书消息）。
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)
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;
}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;
certificate_types This field is a list of the types of certificates requested, sorted in order of the server's preference.
证书类型此字段是请求的证书类型的列表，按服务器的首选项排序。
certificate_authorities A list of the distinguished names of acceptable certificate authorities. 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 both known roots and 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.
证书颁发机构可接受证书颁发机构的可分辨名称列表。这些可分辨名称可以为根CA或从属CA指定所需的可分辨名称；因此，此消息可用于描述已知根和所需授权空间。如果证书颁发机构列表为空，则客户机可以发送相应ClientCertificateType的任何证书，除非有与此相反的外部安排。
ClientCertificateType values are divided into three groups:
ClientCertificateType值分为三组：
1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are reserved for IETF Standards Track protocols.
1. 0（零）到63位小数（0x3F）之间的值保留给IETF标准跟踪协议。
2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive are reserved for assignment for non-Standards Track methods.
2. 保留从64位小数（0x40）到223位小数（0xDF）的值，用于非标准轨迹方法的赋值。
3. Values from 224 decimal (0xE0) through 255 decimal (0xFF) inclusive are reserved for private use.
3. 从224位小数（0xE0）到255位小数（0xFF）的值保留供私人使用。
Additional information describing the role of IANA in the allocation of ClientCertificateType code points is described in Section 11.
第11节描述了IANA在分配ClientCertificateType代码点中的作用的其他信息。
Note: Values listed as RESERVED may not be used. They were used in SSLv3.
注：不得使用列为保留的值。它们在SSLv3中使用。
Note: DistinguishedName is derived from [X501]. DistinguishedNames are represented in DER-encoded format.
注：DifferentiedName源自[X501]。区分名称以DER编码格式表示。
Note: It is a fatal handshake_failure alert for an anonymous server to request client authentication.
注意：这是匿名服务器请求客户端身份验证的致命握手失败警报。
When this message will be sent:
将发送此消息的时间：
The server hello done message is sent by the server to indicate the end of the server hello and associated messages. After sending this message, the server will wait for a client response.
服务器发送服务器hello done消息以指示服务器hello和相关消息的结束。发送此消息后，服务器将等待客户端响应。
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 server hello done message, the client SHOULD verify that the server provided a valid certificate, if required and check that the server hello parameters are acceptable.
在收到服务器hello done消息后，客户端应验证服务器是否提供了有效的证书（如果需要），并检查服务器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 server hello done message. This message is only sent if the server requests a certificate. If no suitable certificate is available, the client SHOULD send a certificate message containing no certificates. That is, the certificate_list structure has a length of zero. If client authentication is required by the server for the handshake to continue, it may respond with a fatal handshake failure alert. Client certificates are sent using the Certificate structure defined in Section 7.4.2.
这是客户端在收到服务器hello done消息后可以发送的第一条消息。仅当服务器请求证书时，才会发送此消息。如果没有合适的证书可用，客户端应发送不包含证书的证书消息。也就是说，证书列表结构的长度为零。如果服务器需要客户端身份验证才能继续握手，它可能会发出致命握手失败警报。使用第7.4.2节中定义的证书结构发送客户端证书。
Note: When using a static Diffie-Hellman based key exchange method (DH_DSS or DH_RSA), if client authentication is requested, the Diffie-Hellman group and generator encoded in the client's certificate MUST match the server specified Diffie-Hellman parameters if the client's parameters are to be used for the key exchange.
注意：当使用基于Diffie-Hellman的静态密钥交换方法（DH_DSS或DH_RSA）时，如果请求客户端身份验证，则客户端证书中编码的Diffie-Hellman组和生成器必须与服务器指定的Diffie-Hellman参数匹配（如果客户端的参数用于密钥交换）。
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 server hello done message.
此消息始终由客户端发送。如果发送了客户端证书消息，它必须立即跟随该消息。否则，它必须是客户端在收到服务器hello done消息后发送的第一条消息。
Meaning of this message:
此信息的含义：
With this message, the premaster secret is set, either though 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. When the key exchange method is DH_RSA or DH_DSS, client certification has been requested, and the client was able to respond with a certificate that contained a Diffie-Hellman public key whose parameters (group and generator) matched those specified by the server in its certificate, this message MUST not contain any data.
通过此消息，可以通过直接传输RSA加密的秘密或通过传输Diffie-Hellman参数来设置premaster秘密，这将允许双方同意相同的premaster秘密。当密钥交换方法为DH_RSA或DH_DSS时，已请求客户端证书，并且客户端能够使用包含Diffie Hellman公钥的证书进行响应，该公钥的参数（组和生成器）与服务器在其证书中指定的参数相匹配，此消息不得包含任何数据。
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 diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: 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 or the temporary RSA key
如果RSA用于密钥协商和身份验证，客户端将生成一个48字节的premaster密钥，并使用服务器证书中的公钥或临时RSA密钥对其进行加密
provided in a server key exchange message, and sends the result in an encrypted premaster secret message. This structure is a variant of the client key exchange message and is not a message in itself.
在服务器密钥交换消息中提供，并将结果发送到加密的premaster机密消息中。此结构是客户端密钥交换消息的变体，而不是消息本身。
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 roll-back attacks. Upon receiving the premaster secret, the server SHOULD check that this value matches the value transmitted by the client in the client hello message.
客户端版本客户端支持的最新（最新）版本。这用于检测版本回滚攻击。收到premaster机密后，服务器应检查该值是否与客户端hello消息中客户端传输的值匹配。
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: An attack discovered by Daniel Bleichenbacher [BLEI] can be used to attack a TLS server that is using PKCS#1 v 1.5 encoded RSA. The attack takes advantage of the fact that, by failing in different ways, a TLS server can be coerced into revealing whether a particular message, when decrypted, is properly PKCS#1 v1.5 formatted or not.
注意：Daniel Bleichenbacher[BLEI]发现的攻击可用于攻击使用PKCS#1 v 1.5编码RSA的TLS服务器。该攻击利用了这样一个事实，即通过以不同的方式失败，TLS服务器可以被强制显示特定消息在解密时是否正确格式化为PKCS#1 v1.5。
The best way to avoid vulnerability to this attack is to treat incorrectly formatted messages in a manner indistinguishable from correctly formatted RSA blocks. Thus, when a server receives an incorrectly formatted RSA block, it should generate a random 48-byte value and proceed using it as the premaster secret. Thus, the server will act identically whether the received RSA block is correctly encoded or not.
避免此攻击漏洞的最佳方法是以与正确格式化的RSA块无法区分的方式处理格式错误的消息。因此，当服务器接收到格式不正确的RSA块时，它应该生成一个随机的48字节值，并继续将其用作premaster机密。因此，无论接收到的RSA块是否正确编码，服务器都将以相同的方式工作。
[PKCS1B] defines a newer version of PKCS#1 encoding that is more secure against the Bleichenbacher attack. However, for maximal compatibility with TLS 1.0, TLS 1.1 retains the original encoding. No variants of the Bleichenbacher attack
[PKCS1B]定义了PKCS#1编码的更新版本，该编码更安全，可以抵御Bleichenbacher攻击。然而，为了最大限度地兼容TLS1.0，TLS1.1保留了原始编码。没有Bleichenbacher攻击的变种
are known to exist provided that the above recommendations are followed.
如果遵循上述建议，则已知存在。
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, encoding 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 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.
此规范要求正确编码EncryptedPreMasterSecret，并包含长度字节。生成的PDU与许多SSLv3实现不兼容。从SSLv3升级的实现者必须修改其实现以生成并接受正确的编码。希望与SSLv3和TLS兼容的实现者应该使其实现的行为依赖于协议版本。
Implementation Note: It is now known that remote timing-based attacks on SSL are possible, at least when the client and server are on the same LAN. Accordingly, implementations that use static RSA keys SHOULD use RSA blinding or some other anti-timing technique, as described in [TIMING].
实施说明：现在已经知道，至少当客户端和服务器位于同一局域网上时，基于SSL的远程定时攻击是可能的。因此，使用静态RSA密钥的实现应该使用RSA致盲或其他一些反计时技术，如[计时]中所述。
Note: The version number in the PreMasterSecret MUST be the version offered by the client in the ClientHello, not the version negotiated for the connection. This feature is designed to prevent rollback attacks. Unfortunately, many implementations use the negotiated version instead, and therefore checking the version number may lead to failure to interoperate with such incorrect client implementations. Client implementations, MUST and Server implementations MAY, check the version number. In practice, since the TLS handshake MACs prevent downgrade and no good attacks are known on those MACs, ambiguity is not considered a serious security risk. Note that if servers choose to check the version number, they should randomize the
注意：PreMasterSecret中的版本号必须是客户端在ClientHello中提供的版本，而不是为连接协商的版本。此功能旨在防止回滚攻击。不幸的是，许多实现使用协商版本，因此检查版本号可能导致无法与此类错误的客户端实现进行互操作。客户端实现，必须和服务器实现，检查版本号。在实践中，由于TLS握手MAC可以防止降级，并且这些MAC上没有已知的良好攻击，因此模糊性不被视为严重的安全风险。请注意，如果服务器选择检查版本号，则应随机化
PreMasterSecret in case of error, rather than generate an alert, in order to avoid variants on the Bleichenbacher attack. [KPR03]
PreMasterSecret在发生错误时，而不是生成警报，以避免Bleichenbacher攻击的变体。[KPR03]
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 certificate already contains a suitable Diffie-Hellman key, 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密钥，则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 {
Signature signature;
} CertificateVerify;
struct {
Signature signature;
} CertificateVerify;
The Signature type is defined in 7.4.3.
签名类型在7.4.3中定义。
CertificateVerify.signature.md5_hash MD5(handshake_messages);
CertificateVerify.signature.md5\u哈希md5（握手消息）；
CertificateVerify.signature.sha_hash SHA(handshake_messages);
CertificateVerify.signature.sha_hash sha（握手消息）；
Here handshake_messages refers to all handshake messages sent or received starting at client hello 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 7.4, exchanged thus far.
这里，握手_消息是指从客户端hello开始发送或接收到的所有握手消息，直到但不包括此消息，包括握手消息的类型和长度字段。这是迄今为止交换的所有握手结构的串联，如7.4中所定义。
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 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.
完成的消息是第一个使用刚刚协商的算法、密钥和机密进行保护的消息。完成邮件的收件人必须验证内容是否正确。一旦一方发送了完成的消息并从其对等方接收并验证了完成的消息，它就可以开始通过连接发送和接收应用程序数据。
struct {
opaque verify_data[12];
} Finished;
struct {
opaque verify_data[12];
} Finished;
verify_data
PRF(master_secret, finished_label, MD5(handshake_messages) +
SHA-1(handshake_messages)) [0..11];
verify_data
PRF(master_secret, finished_label, MD5(handshake_messages) +
SHA-1(handshake_messages)) [0..11];
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”。
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 7.4, exchanged thus far.
握手\消息此握手中所有消息（不包括任何HelloRequest消息）中的所有数据，直到但不包括此消息。这是握手层上唯一可见的数据，不包括记录层标题。这是迄今为止交换的所有握手结构的串联，如7.4中所定义。
It is a fatal error if a finished message is not preceded by a change cipher spec message at the appropriate point in the handshake.
如果在握手的适当位置，完成的消息前面没有更改密码规范消息，则这是一个致命错误。
The value handshake_messages includes all handshake messages starting at client hello 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 certificate verify 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包括从客户端hello开始直到（但不包括）此完成消息的所有握手消息。这可能不同于第7.4.8节中的握手消息，因为它将包括证书验证消息（如果已发送）。此外，客户端发送的已完成消息的握手_消息将与服务器发送的已完成消息的握手_消息不同，因为第二次发送的握手_消息将包括前一次。
Note: Change cipher spec messages, alerts, and any other record types are not handshake messages and are not included in the hash computations. Also, Hello Request messages are omitted from handshake hashes.
注意：更改密码规范消息、警报和任何其他记录类型不是握手消息，也不包括在哈希计算中。此外，握手哈希中省略了Hello请求消息。
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 server hello 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算法由服务器选择并在服务器hello消息中显示的密码套件确定。压缩算法在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，如上所述。
RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1. RSA public key encryption is performed using PKCS #1 block type 2.
RSA数字签名使用PKCS#1[PKCS1]块类型1执行。RSA公钥加密使用PKCS#1块类型2执行。
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_3DES_EDE_CBC_SHA.
在没有应用程序配置文件标准另有规定的情况下，符合TLS的应用程序必须使用\u 3DES\u EDE\u CBC\u SHA实现密码套件TLS\u RSA\u。
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 describes a number of new registries that have been created by IANA. We recommended that they be placed as individual registries items under a common TLS category.
本文档描述了IANA创建的许多新注册中心。我们建议将它们作为单独的登记项目置于通用TLS类别下。
Section 7.4.3 describes a TLS ClientCertificateType Registry to be maintained by the IANA, defining a number of such code point identifiers. ClientCertificateType identifiers with values in the range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards Action. Values from the range 64-223 (decimal) inclusive are assigned via [RFC2434] Specification Required. Identifier values from 224-255 (decimal) inclusive are reserved for RFC 2434 Private Use. The registry will initially be populated with the values in this document, Section 7.4.4.
第7.4.3节描述了由IANA维护的TLS ClientCertificateType注册表，定义了许多这样的代码点标识符。ClientCertificateType标识符的值范围为0-63（十进制），通过RFC 2434标准操作分配。范围64-223（十进制）的值通过所需的[RFC2434]规范分配。224-255（十进制）的标识符值保留给RFC 2434专用。注册表最初将填充本文件第7.4.4节中的值。
Section A.5 describes a TLS Cipher Suite Registry to be maintained by the IANA, and it defines a number of such cipher suite identifiers. Cipher suite values with the first byte in the range 0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action. Values with the first byte in the range 192-254 (decimal) are assigned via RFC 2434 Specification Required. Values with the first byte 255 (decimal) are reserved for RFC 2434 Private Use. The registry will initially be populated with the values from Section A.5 of this document, [TLSAES], and from Section 3 of [TLSKRB].
第A.5节描述了由IANA维护的TLS密码套件注册表，并定义了大量此类密码套件标识符。第一个字节在0-191（十进制）范围内（含）的密码套件值通过RFC 2434标准操作分配。第一个字节在192-254（十进制）范围内的值通过RFC 2434规范指定。第一个字节为255（十进制）的值保留给RFC 2434专用。注册表最初将填充本文件第A.5节[TLSAES]和第3节[TLSKRB]中的值。
Section 6 requires that all ContentType values be defined by RFC 2434 Standards Action. IANA has created a TLS ContentType registry, initially populated with values from Section 6.2.1 of this document. Future values MUST be allocated via Standards Action as described in [RFC2434].
第6节要求所有ContentType值都由RFC 2434标准操作定义。IANA已经创建了一个TLS ContentType注册表，最初由本文档第6.2.1节中的值填充。未来值必须通过[RFC2434]中所述的标准操作进行分配。
Section 7.2.2 requires that all Alert values be defined by RFC 2434 Standards Action. IANA has created a TLS Alert registry, initially populated with values from Section 7.2 of this document and from Section 4 of [TLSEXT]. Future values MUST be allocated via Standards Action as described in [RFC2434].
第243C.4节规定的所有警报值。IANA创建了TLS警报注册表，最初使用本文件第7.2节和[TLSEXT]第4节中的值填充。未来值必须通过[RFC2434]中所述的标准操作进行分配。
Section 7.4 requires that all HandshakeType values be defined by RFC 2434 Standards Action. IANA has created a TLS HandshakeType registry, initially populated with values from Section 7.4 of this document and from Section 2.4 of [TLSEXT]. Future values MUST be allocated via Standards Action as described in [RFC2434].
第7.4节要求所有握手类型值由RFC 2434标准行动定义。IANA已经创建了一个TLS握手类型注册表，最初由本文档第7.4节和[TLSEXT]第2.4节中的值填充。未来值必须通过[RFC2434]中所述的标准操作进行分配。
This section describes protocol types and constants.
本节介绍协议类型和常量。
struct {
uint8 major, minor;
} ProtocolVersion;
struct {
uint8 major, minor;
} ProtocolVersion;
ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */
ProtocolVersion version = { 3, 2 }; /* TLS v1.1 */
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 (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
block-ciphered struct {
opaque IV[CipherSpec.block_length];
block-ciphered struct {
opaque IV[CipherSpec.block_length];
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
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(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),
(255)
} AlertDescription;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(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),
(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-1>;
CompressionMethod compression_methods<1..2^8-1>;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
}克利恩泰罗；
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
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 { rsa, diffie_hellman } KeyExchangeAlgorithm;
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct {
opaque rsa_modulus<1..2^16-1>;
opaque rsa_exponent<1..2^16-1>;
} ServerRSAParams;
struct {
opaque rsa_modulus<1..2^16-1>;
opaque rsa_exponent<1..2^16-1>;
} ServerRSAParams;
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams;
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
case rsa:
ServerRSAParams params;
};
} ServerParams;
case rsa:
ServerRSAParams params;
};
} ServerParams;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque md5_hash[16];
opaque sha_hash[20];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
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 diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: 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 {
Signature signature;
} CertificateVerify;
struct {
Signature signature;
} CertificateVerify;
struct {
opaque verify_data[12];
} Finished;
struct {
opaque verify_data[12];
} Finished;
The following values define the CipherSuite codes used in the client hello and server hello messages.
以下值定义了客户端hello和服务器hello消息中使用的密码套件代码。
A CipherSuite defines a cipher specification supported in TLS Version 1.1.
密码套件定义TLS版本1.1中支持的密码规范。
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 either an RSA or a DSS signature-capable certificate in the certificate request message.
以下密码套件定义要求服务器提供可用于密钥交换的RSA证书。服务器可以在证书请求消息中请求支持RSA或DSS签名的证书。
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
The following CipherSuite 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 DSS or RSA certificate that has been signed by the CA. The signing algorithm used is specified after the DH or DHE parameter. The server can request an RSA or DSS 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签名的DSS或RSA证书签名。使用的签名算法在DH或DHE参数后指定。服务器可以从客户端请求支持RSA或DSS签名的证书以进行客户端身份验证，也可以请求Diffie-Hellman证书。客户端提供的任何Diffie-Hellman证书都必须使用服务器描述的参数（组和生成器）。
CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
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 and is therefore deprecated.
以下密码套件用于完全匿名的Diffie-Hellman通信，其中任何一方都没有经过身份验证。请注意，此模式容易受到中间人攻击，因此不推荐使用。
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
When SSLv3 and TLS 1.0 were designed, the United States restricted the export of cryptographic software containing certain strong encryption algorithms. A series of cipher suites were designed to operate at reduced key lengths in order to comply with those regulations. Due to advances in computer performance, these algorithms are now unacceptably weak, and export restrictions have since been loosened. TLS 1.1 implementations MUST NOT negotiate these cipher suites in TLS 1.1 mode. However, for backward compatibility they may be offered in the ClientHello for use with TLS
在设计SSLv3和TLS1.0时，美国限制了包含某些强加密算法的加密软件的出口。为了遵守这些规定，设计了一系列密码套件，以缩短密钥长度进行操作。由于计算机性能的进步，这些算法现在弱得令人无法接受，出口限制也因此放松。TLS 1.1实现不得在TLS 1.1模式下协商这些密码套件。但是，为了向后兼容，ClientHello中可能会提供它们用于TLS
1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the server did not choose one of these cipher suites during the handshake. These ciphersuites are listed below for informational purposes and to reserve the numbers.
1.0 或仅限SSLv3服务器。TLS 1.1客户端必须检查服务器在握手过程中是否没有选择这些密码套件之一。下面列出了这些密码套件，以供参考并保留数字。
CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
The following cipher suites were defined in [TLSKRB] and are included here for completeness. See [TLSKRB] for details:
[TLSKRB]中定义了以下密码套件，为完整起见，将其包含在此处。有关详细信息，请参见[TLSKRB]：
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }:
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }:
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
The following exportable cipher suites were defined in [TLSKRB] and are included here for completeness. TLS 1.1 implementations MUST NOT negotiate these cipher suites.
[TLSKRB]中定义了以下可导出密码套件，为完整起见，此处将其包括在内。TLS 1.1实现不得协商这些密码套件。
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28};
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B};
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28};
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B};
The following cipher suites were defined in [TLSAES] and are included here for completeness. See [TLSAES] for details:
[TLSAES]中定义了以下密码套件，为完整起见，此处将其包括在内。有关详细信息，请参见[TLSAES]：
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
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_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
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_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 };
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_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 };
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_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A };
The cipher suite space is divided into three regions:
密码套件空间分为三个区域：
1. Cipher suite values with first byte 0x00 (zero) through decimal 191 (0xBF) inclusive are reserved for the IETF Standards Track protocols.
1. 第一个字节为0x00（零）到十进制191（0xBF）（含）的密码套件值保留给IETF标准跟踪协议。
2. Cipher suite values with first byte decimal 192 (0xC0) through decimal 254 (0xFE) inclusive are reserved for assignment for non-Standards Track methods.
2. 第一个字节小数点192（0xC0）到小数点254（0xFE）的密码套件值保留用于非标准跟踪方法的分配。
3. Cipher suite values with first byte 0xFF are reserved for private use.
3. 第一个字节为0xFF的密码套件值保留供私人使用。
Additional information describing the role of IANA in the allocation of cipher suite code points is described in Section 11.
第11节描述了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 { null, rc4, rc2, des, 3des, des40, aes, idea }
BulkCipherAlgorithm;
enum { null, rc4, rc2, des, 3des, des40, aes, idea }
BulkCipherAlgorithm;
enum { stream, block } CipherType;
enum { stream, block } CipherType;
enum { null, md5, sha } MACAlgorithm;
enum { null, md5, sha } MACAlgorithm;
/* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
/* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct {
ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
struct {
ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
Advanced Encryption Standard (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. [AES] TLS currently only supports the 128 and 256 bit key sizes.
高级加密标准（AES）AES是一种广泛使用的对称加密算法。AES是一种具有128、192或256位密钥和16字节块大小的分组密码。[AES]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.
非对称密码参见公钥密码术。
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 is a common block size.
分组密码分组密码是一种以位为单位对明文进行运算的算法，称为块。64位是常见的块大小。
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 secret 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 is a very widely used symmetric encryption algorithm. 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 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 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]
数据加密标准DES是一种应用非常广泛的对称加密算法。DES是一种具有56位密钥和8字节块大小的分组密码。请注意，在TLS中，出于密钥生成目的，DES被视为具有8字节密钥长度（64位），但它仍然仅提供56位保护。（假定每个密钥字节的低位被设置为在该密钥字节中产生奇偶校验。）DES也可以在一种模式下运行，其中每个数据块使用三个独立密钥和三个加密；这使用168位密钥（在TLS密钥生成方法中为24字节），并提供相当于112位的安全性。[DES]，[3DES]
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, "Digital Signature Standard," published May 1994 by the U.S. Dept. of Commerce. [DSS]
数字签名标准（DSS）：美国国家标准与技术研究所批准的数字签名标准，包括数字签名算法，由美国商务部于1994年5月发布的NIST FIPS PUB 186“数字签名标准”中定义。[决策支持系统]
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模式下使用时，初始化向量在加密之前与第一个明文块进行异或运算。
IDEA A 64-bit block cipher designed by Xuejia Lai and James Massey. [IDEA]
Lai和James Massey设计的64位分组密码。[想法]
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 is a secure hashing function that converts an arbitrarily long data stream into a digest of fixed size (16 bytes). [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是单向散列函数的示例。
RC2 A block cipher developed by Ron Rivest at RSA Data Security, Inc. [RSADSI] described in [RC2].
RC2由RSA Data Security，Inc.[RSADSI]的Ron Rivest开发的分组密码，如[RC2]所述。
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 under 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 secret The secret data used to authenticate data written by the server.
服务器写入MAC机密用于验证服务器写入的数据的机密数据。
SHA The Secure Hash Algorithm is defined in FIPS PUB 180-2. It produces a 20-byte output. Note that all references to SHA actually use the modified SHA-1 algorithm. [SHA]
SHA安全哈希算法在FIPS PUB 180-2中定义。它产生一个20字节的输出。请注意，所有对SHA的引用实际上都使用修改后的SHA-1算法。[民政事务局局长]
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 "Comments" at the end of this document.
传输层安全（TLS）协议；此外，互联网工程任务组（IETF）的传输层安全工作组。见本文件末尾的“评论”。
CipherSuite Key Exchange Cipher Hash
CipherSuite密钥交换密码散列
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_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_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_DES_CBC_SHA DH_anon DES_CBC SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
我们的研究结果是一个零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零零在过去的一些研究中，我们的研究结果是在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究中，在过去的一些研究结果是在过去的一些研究结果是在过去的一些研究中，在过去的数据是在过去的数据和过去的数据，在过去的数据和过去的数据和过去的数据和过去的数据和过去的数据，在过去的数据和过去的数据和过去的数据和过去的数据，在过去的数据和过去的数据和过去的数据，在过去的数据和过去的数据和过去的数据和过去的数据和过去的数据和过去的数据和过去的数据和过去的数据和过去的数据和过去的数据和过去的数据和与CBC合作的DSS\U与CBC合作的DSS\U与CBC合作的DSS\U与CBC合作的DSS\U与CBC合作的RSA\U与CBC合作的DSS\U与CBC合作的DSS\U与CBC合作的DSS\U这是一个非常重要的问题
Key Exchange Algorithm Description Key size limit
密钥交换算法描述密钥大小限制
DHE_DSS Ephemeral DH with DSS signatures None DHE_RSA Ephemeral DH with RSA signatures None DH_anon Anonymous DH, no signatures None DH_DSS DH with DSS-based certificates None DH_RSA DH with RSA-based certificates None RSA = none NULL No key exchange N/A RSA RSA key exchange None
DHE_DSS带有DSS签名的临时DH无DHE_RSA带有RSA签名的临时DH无DH_anon匿名DH，无签名无DH_DSS DH带有基于DSS的证书无DH_RSA DH带有基于RSA的证书无RSA=无空无密钥交换N/A RSA密钥交换无
Key Expanded IV Block Cipher Type Material Key Material Size Size
密钥扩展IV分组密码类型材质密钥材质大小
NULL Stream 0 0 0 N/A IDEA_CBC Block 16 16 8 8 RC2_CBC_40 Block 5 16 8 8 RC4_40 Stream 5 16 0 N/A RC4_128 Stream 16 16 0 N/A DES40_CBC Block 5 8 8 8 DES_CBC Block 8 8 8 8 3DES_EDE_CBC Block 24 24 8 8
零流0 0 0 N/A创意CBC区块16 16 8 8 RC2 8 CBC区块5 16 8 RC4 40流5 16 0 N/A RC4 4 U 128流16 0 N/A设计CBC区块5 8 8设计CBC区块24 8 8
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键块中用于生成写入键的字节数。
Expanded Key Material The number of bytes actually fed into the encryption algorithm.
扩展密钥材料实际输入加密算法的字节数。
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.
IV Size初始化向量需要生成的数据量。流密码为零；等于分组密码的块大小。
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模式下运行的分组密码只能加密其块大小的偶数倍。
Hash Hash Padding function Size Size NULL 0 0 MD5 16 48 SHA 20 40
哈希填充函数大小NULL 0 0 MD5 16 48 SHA 20 40
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 MD5 and/or SHA, are acceptable, but cannot provide more security than the size of the random number generator state. (For example, MD5-based PRNGs usually provide 128 bits of state.)
TLS需要加密安全的伪随机数生成器（PRNG）。在设计和播种PRNG时必须小心。基于安全散列操作（最显著的是MD5和/或SHA）的PRNG是可以接受的，但不能提供比随机数生成器状态更大的安全性。（例如，基于MD5的PRNG通常提供128位状态。）
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 example, 40-bit encryption is easily broken, so implementations requiring strong security should not allow 40-bit keys. Similarly, 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支持一系列密钥大小和安全级别，包括一些不提供安全性或最低安全性的密钥。正确的实现可能不支持许多密码套件。例如，40位加密很容易被破坏，因此需要强安全性的实现不应该允许使用40位密钥。类似地，匿名Diffie Hellman也被强烈劝阻，因为它无法阻止中间人攻击。应用程序还应强制执行最小和最大密钥大小。例如，包含512位RSA密钥或签名的证书链不适用于高安全性应用程序。
For historical reasons and in order to avoid a profligate consumption of reserved port numbers, application protocols that are secured by TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 all frequently share the same connection port. For example, the https protocol (HTTP secured by SSL or TLS) uses port 443 regardless of which security protocol it is using. Thus, some mechanism must be determined to distinguish and negotiate among the various protocols.
出于历史原因，并且为了避免浪费保留端口号，由TLS 1.1、TLS 1.0、SSL 3.0和SSL 2.0保护的应用程序协议通常共享同一个连接端口。例如，https协议（由SSL或TLS保护的HTTP）使用端口443，而不管它使用的是哪种安全协议。因此，必须确定某种机制来区分和协商各种协议。
TLS versions 1.1 and 1.0, and SSL 3.0 are very similar; thus, supporting both is easy. TLS clients who wish to negotiate with such older servers SHOULD send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 2} for the version field to note that they support TLS 1.1. If the server supports only TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello; if it supports TLS 1.1 it will respond with a TLS 1.1 server hello. The negotiation then proceeds as appropriate for the negotiated protocol.
TLS版本1.1和1.0以及SSL 3.0非常相似；因此，支持两者都很容易。希望与此类较旧服务器协商的TLS客户端应使用SSL 3.0记录格式和客户端hello结构发送客户端hello消息，并为版本字段发送{3，2}，以注意它们支持TLS 1.1。如果服务器仅支持TLS 1.0或SSL 3.0，它将使用downrev 3.0服务器hello进行响应；如果它支持TLS 1.1，它将用TLS 1.1服务器hello响应。然后，根据谈判达成的协议进行适当的谈判。
Similarly, a TLS 1.1 server that wishes to interoperate with TLS 1.0 or SSL 3.0 clients SHOULD accept SSL 3.0 client hello messages and respond with a SSL 3.0 server hello if an SSL 3.0 client hello with a version field of {3, 0} is received, denoting that this client does not support TLS. Similarly, if a SSL 3.0 or TLS 1.0 hello with a version field of {3, 1} is received, the server SHOULD respond with a TLS 1.0 hello with a version field of {3, 1}.
类似地，如果接收到版本字段为{3，0}的SSL 3.0客户端hello，则希望与TLS 1.0或SSL 3.0客户端互操作的TLS 1.1服务器应接受SSL 3.0客户端hello消息，并使用SSL 3.0服务器hello响应，这表示此客户端不支持TLS。类似地，如果收到版本字段为{3，1}的SSL 3.0或TLS 1.0 hello，则服务器应以版本字段为{3，1}的TLS 1.0 hello响应。
Whenever a client already knows the highest protocol known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol.
只要客户机已经知道服务器已知的最高协议（例如，在恢复会话时），它就应该以该本机协议启动连接。
TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL Version 2.0 client hello messages [SSL2]. TLS servers SHOULD accept either client hello format if they wish to support SSL 2.0 clients on the same connection port. The only deviations from the Version 2.0 specification are the ability to specify a version with a value of three and the support for more ciphering types in the CipherSpec.
支持SSL版本2.0服务器的TLS 1.1客户端必须发送SSL版本2.0客户端hello消息[SSL2]。如果TLS服务器希望在同一连接端口上支持SSL 2.0客户端，则应接受任一客户端hello格式。与版本2.0规范的唯一不同之处是能够指定一个值为3的版本，以及在CipherSpec中支持更多的加密类型。
Warning: The ability to send Version 2.0 client hello messages will be phased out with all due haste. Implementors SHOULD make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for moving to newer versions.
警告：发送2.0版客户机hello消息的功能将被逐步取消。实施者应尽一切努力尽快向前推进。版本3.0为移动到新版本提供了更好的机制。
The following cipher specifications are carryovers from SSL Version 2.0. These are assumed to use RSA for key exchange and authentication.
以下密码规范是SSL 2.0版的延续。假设它们使用RSA进行密钥交换和身份验证。
V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
= { 0x04,0x00,0x80 };
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
= { 0x04,0x00,0x80 };
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
Cipher specifications native to TLS can be included in Version 2.0 client hello messages using the syntax below. Any V2CipherSpec element with its first byte equal to zero will be ignored by Version 2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD also include the TLS equivalent (see Appendix A.5):
TLS固有的密码规范可以使用以下语法包含在2.0版客户端hello消息中。版本2.0服务器将忽略第一个字节等于零的V2CipherSpec元素。发送上述V2CipherSpec的客户还应包括TLS等效物（见附录A.5）：
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
Note: TLS 1.1 clients may generate the SSLv2 EXPORT cipher suites in handshakes for backward compatibility but MUST NOT negotiate them in TLS 1.1 mode.
注意：TLS 1.1客户端可以通过握手方式生成SSLv2导出密码套件，以实现向后兼容性，但不得在TLS 1.1模式下协商。
The Version 2.0 client hello message is presented below using this document's presentation model. The true definition is still assumed to be the SSL Version 2.0 specification. Note that this message MUST be sent directly on the wire, not wrapped as an SSLv3 record
下面使用本文档的表示模型显示了2.0版客户端hello消息。真正的定义仍然假定为SSL版本2.0规范。请注意，此消息必须直接在线路上发送，而不是包装为SSLv3记录
uint8 V2CipherSpec[3];
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;
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 This field is the length of the following data in bytes. The high bit MUST be 1 and is not part of the length.
msg_length此字段是以下数据的长度（以字节为单位）。高位必须为1，并且不是长度的一部分。
msg_type This field, in conjunction with the version field, identifies a version 2 client hello message. The value SHOULD be one (1).
msg_type此字段与version字段一起标识version 2客户端hello消息。该值应为一（1）。
version The highest version of the protocol supported by the client (equals ProtocolVersion.version; see Appendix A.1).
版本客户端支持的协议的最高版本（等于ProtocolVersion.version；见附录A.1）。
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.
会话\u id\u长度此字段的值必须为零。
challenge_length The length in bytes of the client's challenge to the server to authenticate itself. When using the SSLv2 backward compatible handshake the client MUST use a 32-byte challenge.
challenge_length客户端向服务器发出的验证自身身份的质询的长度（以字节为单位）。使用SSLv2向后兼容握手时，客户端必须使用32字节的质询。
cipher_specs This is a list of all CipherSpecs the client is willing and able to use. There MUST be at least one CipherSpec acceptable to the server.
密码规格这是客户愿意并能够使用的所有密码规格的列表。必须至少有一个服务器可接受的CipherSpec。
session_id This field MUST be empty.
会话id此字段必须为空。
challenge The client challenge to the server for the server to identify itself is a (nearly) arbitrary-length random. The TLS server will right-justify the challenge data to become the ClientHello.random data (padded with leading zeroes, if necessary), as specified in this protocol specification. If the length of the challenge is greater than 32 bytes, only the last 32 bytes are used. It is legitimate (but not necessary) for a V3 server to reject a V2 ClientHello that has fewer than 16 bytes of challenge data.
质询客户端对服务器的质询是（几乎）任意长度的随机质询。按照本协议规范的规定，TLS服务器将正确证明质询数据成为ClientHello.random数据（如有必要，用前导零填充）。如果质询的长度大于32字节，则仅使用最后32字节。V3服务器拒绝具有少于16字节质询数据的V2 ClientHello是合法的（但不是必需的）。
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 SHOULD 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 TLS clients are in Version 2.0 compatibility mode, they 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). After decrypting the ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an error if these eight padding bytes are 0x03. Version 2.0 servers receiving blocks padded in this manner will proceed normally.
当TLS客户端处于版本2.0兼容模式时，它们将PKCS填充的右侧（最低有效）8个随机字节（不包括填充的终端null）设置为0x03（其他填充字节是随机的），以便对CLIENT-MASTER-KEY的ENCRYPTED-KEY-DATA字段进行RSA加密。解密加密的-KEY-DATA字段后，如果这八个填充字节为0x03，则支持TLS的服务器应发出错误。接收以这种方式填充的块的2.0版服务器将正常运行。
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 CipherSpec 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
TLS支持三种身份验证模式：双方身份验证、未经身份验证的客户端的服务器身份验证和完全匿名。只要服务器经过身份验证，通道就可以安全地抵御中间人攻击，但完全匿名会话本身就容易受到此类攻击。匿名服务器无法对客户端进行身份验证。如果服务器经过身份验证，则其证书消息必须提供一个有效的证书链，指向可接受的证书颁发机构。类似地，经过身份验证的客户端必须向
server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked.
服务器各方负责验证另一方的证书是否有效且未过期或被撤销。
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 secrets (see Sections 7.4.8, 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.8、7.4.9和6.3节）。通过发送正确的完成消息，双方证明他们知道正确的pre_master_机密。
Completely anonymous sessions can be established using RSA or Diffie-Hellman for key exchange. With anonymous RSA, the client encrypts a pre_master_secret with the server's uncertified public key extracted from the server key exchange message. The result is sent in a client key exchange message. Since eavesdroppers do not know the server's private key, it will be infeasible for them to decode the pre_master_secret.
完全匿名会话可以使用RSA或Diffie Hellman建立，用于密钥交换。使用匿名RSA，客户端使用从服务器密钥交换消息中提取的服务器未经认证的公钥对预主密钥进行加密。结果在客户端密钥交换消息中发送。由于窃听者不知道服务器的私钥，因此他们无法解码pre_master_机密。
Note: No anonymous RSA Cipher Suites are defined in this document.
注意：本文档中未定义匿名RSA密码套件。
With Diffie-Hellman, the server's public parameters are contained in the server key exchange message and the client's are sent in the 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，服务器的公共参数包含在服务器密钥交换消息中，而客户端的公共参数则在客户端密钥交换消息中发送。不知道私有值的窃听者不应该能够找到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 either may be contained in the server's certificate or may be a temporary RSA key sent in a server key exchange message. When temporary RSA keys are used, they are signed by the server's RSA certificate. The signature includes the current ClientHello.random, so old signatures and temporary keys cannot be replayed. Servers may use a single temporary RSA key for multiple negotiation sessions.
使用RSA，密钥交换和服务器身份验证结合在一起。公钥可以包含在服务器的证书中，也可以是服务器密钥交换消息中发送的临时RSA密钥。使用临时RSA密钥时，它们由服务器的RSA证书签名。签名包含当前的ClientHello.random，因此无法重放旧签名和临时密钥。服务器可以为多个协商会话使用单个临时RSA密钥。
Note: The temporary RSA key option is useful if servers need large
注意：临时RSA密钥选项在服务器需要大型密钥时非常有用
certificates but must comply with government-imposed size limits on keys used for key exchange.
证书，但必须符合政府对用于密钥交换的密钥施加的大小限制。
Note that if ephemeral RSA is not used, 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 the master_secret and 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节）。客户端对从master_secret和前面所有握手消息派生的值进行签名。这些握手消息包括将签名绑定到服务器的服务器证书和将签名绑定到当前握手过程的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 DSS 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参数的证书，也可以使用服务器密钥交换消息发送一组使用DSS或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., 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.
如果客户机具有包含固定Diffie-Hellman参数的证书，则其证书包含完成密钥交换所需的信息。注意，在这种情况下，客户机和服务器在每次通信时都会生成相同的Diffie-Hellman结果（即pre_master_secret）。为了防止pre_master_secret在内存中停留的时间超过需要，应尽快将其转换为master_secret。客户端Diffie-Hellman参数必须与服务器提供的参数兼容，密钥交换才能工作。
If the client has a standard DSS 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.
如果客户机具有标准DSS或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 ciphersuites 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 ciphersuites.
通过使用一个DHE密码套件并为每次握手生成一个新的DH私钥（X），最容易避免小子组攻击。如果选择合适的基数（如2），则可以非常快速地计算g^X mod p，从而使性能成本最小化。此外，为每次握手使用新密钥提供了完美的前向保密性。当使用DHE密码套件时，实现应该为每次握手生成一个新的X。
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. Parties concerned about attacks of this scale should not use 40-bit encryption keys. Altering the padding of the least-significant 8 bytes of the PKCS 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.
尽管使用非随机PKCS#1 block type 2消息填充的解决方案并不美观，但它为3.0版服务器提供了一种合理安全的方法来检测攻击。此解决方案不安全，攻击者可以在应用程序指定的等待阈值过期之前强行使用密钥并替换包含相同密钥（但具有正常填充）的新加密密钥数据消息。关注这种规模攻击的各方不应使用40位加密密钥。更改PKCS填充的最低有效8字节的填充不会影响协议中使用的签名哈希大小和RSA密钥长度的安全性，因为这本质上相当于将输入块大小增加8字节。
An attacker might try to influence the handshake exchange to make the parties select different encryption algorithms than they would normally chooses.
攻击者可能试图影响握手交换，使双方选择不同于通常选择的加密算法。
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 secrets 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 (which use both SHA and MD5).
当通过恢复会话建立连接时，新的ClientHello.random和ServerHello.random值将使用会话的master_secret散列。如果主密钥未被泄露，并且用于生成加密密钥和MAC密钥的安全哈希操作是安全的，则连接应该是安全的，并且有效地独立于以前的连接。攻击者不能使用已知的加密密钥或MAC机密泄露主密钥，而不破坏安全哈希操作（同时使用SHA和MD5）。
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写入稳定的存储。
TLS uses hash functions very conservatively. Where possible, both MD5 and SHA are used in tandem to ensure that non-catastrophic flaws in one algorithm will not break the overall protocol.
TLS非常保守地使用哈希函数。在可能的情况下，MD5和SHA同时使用，以确保一个算法中的非灾难性缺陷不会破坏整个协议。
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 secret, the sequence number, the message length, the 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 secrets. Similarly, the server-write and client-write keys are independent, so stream cipher keys are used only once.
传出数据在传输前由MAC保护。为了防止消息重播或修改攻击，MAC由MAC密码、序列号、消息长度、消息内容和两个固定字符串计算。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 secrets 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 ciphersuite. 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. 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 ciphersuites 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。该方法确保通过任何一对加密和MAC功能实现完整性和机密性目标，前提是前者对选择的明文攻击是安全的，并且MAC对选择的消息攻击是安全的。TLS使用另一种方法，称为先验证后加密，其中首先在明文上计算MAC，然后对明文和MAC的串联进行加密。这种方法已被证明对加密功能和MAC功能的某些组合是安全的，但不能保证总体上是安全的。特别是，已经证明存在完全安全的加密函数（即使在信息理论意义上也是安全的），这些函数与任何安全的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 pseudo-random generator and this pad is xor-ed 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 previous versions of SSL, 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，则可以显示安全性。在以前的SSL版本中，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 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 denial of service 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-ESP] or ESP [AH-ESP].
由于TLS通过TCP运行，因此它也容易受到对单个连接的大量拒绝服务攻击。特别是，攻击者可以伪造RST，从而终止连接，或者伪造部分TLS记录，从而导致连接暂停。这些攻击通常不能通过TCP使用协议进行防御。与此类攻击相关的实现者或用户应使用IPsec AH[AH-ESP]或ESP[AH-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, 40-bit bulk encryption 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.
该系统仅与所支持的最薄弱的密钥交换和身份验证算法一样强大，并且只能使用可靠的加密功能。使用短公钥、40位批量加密密钥和匿名服务器时应格外小心。在决定哪些证书和证书颁发机构是可接受的时，实现和用户必须小心；不诚实的证书颁发机构会造成巨大的损失。
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] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," IEEE Spectrum, v. 16, n. 7, July 1979, pp. 40-41.
[3DES]W.Tuchman，“Hellman没有为DES提供捷径解决方案”，IEEE Spectrum，v。16，n。1979年7月7日，第40-41页。
[DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption," American National Standards Institute, 1983.
[DES]ANSI X3.106，“美国信息系统数据链路加密国家标准”，美国国家标准协会，1983年。
[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月。
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
[IDEA]X.Lai，“分组密码的设计与安全”，信息处理ETH系列，v。康斯坦茨：哈东·高尔·韦拉格，1992年。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年4月。
[PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 1.5", RFC 2313, March 1998.
[PKCS1A]B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范1.5版”，RFC 2313，1998年3月。
[PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[PKCS1B]J.Jonsson，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.
[2002年4月，福特公共基础设施许可证和证书撤销，Housley，2002年4月。
[RC2] Rivest, R., "A Description of the RC2(r) Encryption Algorithm", RFC 2268, March 1998.
[RC2]Rivest，R.，“RC2（R）加密算法的描述”，RFC 2268，1998年3月。
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2ed", Published by John Wiley & Sons, Inc. 1996.
[SCH]B.Schneier。“应用密码学：C，2ed中的协议、算法和源代码”，由John Wiley&Sons，Inc.于1996年出版。
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce., August 2001.
[SHA]NIST FIPS PUB 180-2，“安全哈希标准”，美国商务部国家标准与技术研究所，2001年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月。
[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月。
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[TLSEXT]Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 35462003年6月。
[TLSKRB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
[TLSKRB]Medvinsky，A.和M.Hur，“将Kerberos密码套件添加到传输层安全性（TLS）”，RFC 2712，1999年10月。
Informative References
资料性引用
[AH-ESP] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[AH-ESP]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
Eastlake 3rd, D., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
Eastlake 3rd，D.，“封装安全有效载荷（ESP）和认证头（AH）的密码算法实现要求”，RFC 4305，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., "Password Interception in a SSL/TLS Channel", http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
[CBCTIME]Canvel，B.，“SSL/TLS通道中的密码拦截”，http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure is SSL?)", Crypto 2001.
[Encouth]Krawczyk，H.，“保护通信的加密和认证顺序（或：SSL有多安全？），《加密2001》。
[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月。
[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月。
[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. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996.
[SSL3]A.Frier，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] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[TCP]Hellstrom，G.和P.Jones，“文本对话的RTP有效负载”，RFC 4103，2005年6月。
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are practical", USENIX Security Symposium 2003.
[定时]Boneh，D.，Brumley，D.，“远程定时攻击是切实可行的”，USENIX安全研讨会2003。
[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月。
[X501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993.
[X501]ITU-T建议X.501：信息技术-开放系统互连-目录：模型，1993年。
[X509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - "The Directory - Authentication Framework". 1988.
[X509]ITU-T建议X.509（1997 E）：信息技术-开放系统互连-“目录-认证框架”。1988
[XDR] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[XDR]Srinivasan，R.，“XDR：外部数据表示标准”，RFC 1832，1995年8月。
Authors' Addresses
作者地址
Working Group Chairs
工作组主席
Win Treese
温特雷斯
EMail: treese@acm.org
EMail: treese@acm.org
Eric Rescorla
埃里克·雷斯科拉
EMail: ekr@rtfm.com
EMail: ekr@rtfm.com
Editors
编辑
Tim Dierks Independent
蒂姆·迪克斯独立报
EMail: tim@dierks.org
EMail: tim@dierks.org
Eric Rescorla RTFM, Inc.
Eric Rescorla RTFM公司。
EMail: ekr@rtfm.com
EMail: ekr@rtfm.com
Other Contributors
其它责任者
Christopher Allen (co-editor of TLS 1.0) Alacrity Ventures EMail: ChristopherA@AlacrityManagement.com
Christopher Allen（TLS 1.0联合编辑）Alacrity Ventures电子邮件：ChristopherA@AlacrityManagement.com
Martin Abadi University of California, Santa Cruz EMail: abadi@cs.ucsc.edu
马丁阿巴迪加利福尼亚大学，圣克鲁斯电子邮件：abadi@cs.ucsc.edu
Ran Canetti IBM EMail: canetti@watson.ibm.com
运行Canetti IBM电子邮件：canetti@watson.ibm.com
Taher Elgamal Securify EMail: taher@securify.com
Taher Elgamal Securify电子邮件：taher@securify.com
Anil Gangolli EMail: anil@busybuddha.org
Anil Gangolli电子邮件：anil@busybuddha.org
Kipp Hickman
基普·希克曼
Phil Karlton (co-author of SSLv3)
菲尔·卡尔顿（SSLv3的合著者）
Paul Kocher (co-author of SSLv3) Cryptography Research EMail: paul@cryptography.com
Paul Kocher（SSLv3的合著者）加密研究电子邮件：paul@cryptography.com
Hugo Krawczyk Technion Israel Institute of Technology EMail: hugo@ee.technion.ac.il
Hugo Krawczyk Technion以色列理工学院电子邮件：hugo@ee.technion.ac.il
Robert Relyea Netscape Communications EMail: relyea@netscape.com
Robert Relyea Netscape通信电子邮件：relyea@netscape.com
Jim Roskind Netscape Communications EMail: jar@netscape.com
Jim Roskind Netscape通信电子邮件：jar@netscape.com
Michael Sabin
迈克尔·萨宾
Dan Simon Microsoft, Inc. EMail: dansimon@microsoft.com
Dan Simon Microsoft，Inc.电子邮件：dansimon@microsoft.com
Tom Weinstein
汤姆温斯坦
Comments
评论
The discussion list for the IETF TLS working group is located at the e-mail address <ietf-tls@lists.consensus.com>. Information on the group and information on how to subscribe to the list is at <http://lists.consensus.com/>.
IETF TLS工作组的讨论列表位于电子邮件地址<IETF-tls@lists.consensus.com>. 有关组的信息以及如何订阅列表的信息，请访问<http://lists.consensus.com/>.
Archives of the list can be found at:
<http://www.imc.org/ietf-tls/mail-archive/>
Archives of the list can be found at:
<http://www.imc.org/ietf-tls/mail-archive/>
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。