Internet Engineering Task Force (IETF) A. Freier
Request for Comments: 6101 P. Karlton
Category: Historic Netscape Communications
ISSN: 2070-1721 P. Kocher
Independent Consultant
August 2011
Internet Engineering Task Force (IETF) A. Freier
Request for Comments: 6101 P. Karlton
Category: Historic Netscape Communications
ISSN: 2070-1721 P. Kocher
Independent Consultant
August 2011
The Secure Sockets Layer (SSL) Protocol Version 3.0
安全套接字层（SSL）协议版本3.0
Abstract
摘要
This document is published as a historical record of the SSL 3.0 protocol. The original Abstract follows.
本文档作为SSL 3.0协议的历史记录发布。原始摘要如下。
This document specifies version 3.0 of the Secure Sockets Layer (SSL 3.0) protocol, a security protocol that provides communications privacy over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.
本文档指定了安全套接字层（SSL 3.0）协议的3.0版本，该协议是一种在Internet上提供通信隐私的安全协议。该协议允许客户机/服务器应用程序以防止窃听、篡改或消息伪造的方式进行通信。
Foreword
前言
Although the SSL 3.0 protocol is a widely implemented protocol, a pioneer in secure communications protocols, and the basis for Transport Layer Security (TLS), it was never formally published by the IETF, except in several expired Internet-Drafts. This allowed no easy referencing to the protocol. We believe a stable reference to the original document should exist and for that reason, this document describes what is known as the last published version of the SSL 3.0 protocol, that is, the November 18, 1996, version of the protocol.
尽管SSL 3.0协议是一种广泛实施的协议，是安全通信协议的先驱，也是传输层安全（TLS）的基础，但它从未由IETF正式发布，除非在几份过期的互联网草案中。这不允许轻松引用协议。我们认为应该存在对原始文档的稳定引用，因此，本文档描述了SSL 3.0协议的最后发布版本，即1996年11月18日的协议版本。
There were no changes to the original document other than trivial editorial changes and the addition of a "Security Considerations" section. However, portions of the original document that no longer apply were not included. Such as the "Patent Statement" section, the "Reserved Ports Assignment" section, and the cipher-suite registrator note in the "The CipherSuite" section. The "US export rules" discussed in the document do not apply today but are kept intact to provide context for decisions taken in protocol design. The "Goals of This Document" section indicates the goals for adopters of SSL 3.0, not goals of the IETF.
除了微不足道的编辑改动和增加了“安全注意事项”一节外，原始文件没有任何改动。但是，不包括原文件中不再适用的部分。例如“专利声明”部分、“保留端口分配”部分，以及“密码套件”部分中的密码套件注册人注释。文件中讨论的“美国出口规则”今天不适用，但保持不变，以便为协议设计中的决策提供背景。“本文档的目标”部分指出了SSL 3.0采用者的目标，而不是IETF的目标。
The authors and editors were retained as in the original document. The editor of this document is Nikos Mavrogiannopoulos (nikos.mavrogiannopoulos@esat.kuleuven.be). The editor would like to thank Dan Harkins, Linda Dunbar, Sean Turner, and Geoffrey Keating for reviewing this document and providing helpful comments.
作者和编辑保留在原始文件中。本文件的编辑是Nikos Mavrogiannopoulos（Nikos。mavrogiannopoulos@esat.kuleuven.be). 编辑要感谢Dan Harkins、Linda Dunbar、Sean Turner和Geoffrey Keating对本文档的审阅并提供了有益的评论。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for the historical record.
本文件不是互联网标准跟踪规范；它是为了历史记录而出版的。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档定义了互联网社区的历史文档。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6101.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6101.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................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. SSL Protocol ...................................................12
5.1. Session and Connection States .............................12
5.2. Record Layer ..............................................14
5.2.1. Fragmentation ......................................14
5.2.2. Record Compression and Decompression ...............15
5.2.3. Record Payload Protection and the CipherSpec .......16
5.3. Change Cipher Spec Protocol ...............................18
5.4. Alert Protocol ............................................18
5.4.1. Closure Alerts .....................................19
5.4.2. Error Alerts .......................................20
5.5. Handshake Protocol Overview ...............................21
5.6. Handshake Protocol ........................................23
5.6.1. Hello messages .....................................24
5.6.2. Server Certificate .................................28
5.6.3. Server Key Exchange Message ........................28
5.6.4. Certificate Request ................................30
5.6.5. Server Hello Done ..................................31
5.6.6. Client Certificate .................................31
5.6.7. Client Key Exchange Message ........................31
5.6.8. Certificate Verify .................................34
5.6.9. Finished ...........................................35
5.7. Application Data Protocol .................................36
6. Cryptographic Computations .....................................36
6.1. Asymmetric Cryptographic Computations .....................36
6.1.1. RSA ................................................36
6.1.2. Diffie-Hellman .....................................37
6.1.3. FORTEZZA ...........................................37
6.2. Symmetric Cryptographic Calculations and the CipherSpec ...37
6.2.1. The Master Secret ..................................37
6.2.2. Converting the Master Secret into Keys and
MAC Secrets ........................................37
7. Security Considerations ........................................39
8. Informative References .........................................40
1. Introduction ....................................................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. SSL Protocol ...................................................12
5.1. Session and Connection States .............................12
5.2. Record Layer ..............................................14
5.2.1. Fragmentation ......................................14
5.2.2. Record Compression and Decompression ...............15
5.2.3. Record Payload Protection and the CipherSpec .......16
5.3. Change Cipher Spec Protocol ...............................18
5.4. Alert Protocol ............................................18
5.4.1. Closure Alerts .....................................19
5.4.2. Error Alerts .......................................20
5.5. Handshake Protocol Overview ...............................21
5.6. Handshake Protocol ........................................23
5.6.1. Hello messages .....................................24
5.6.2. Server Certificate .................................28
5.6.3. Server Key Exchange Message ........................28
5.6.4. Certificate Request ................................30
5.6.5. Server Hello Done ..................................31
5.6.6. Client Certificate .................................31
5.6.7. Client Key Exchange Message ........................31
5.6.8. Certificate Verify .................................34
5.6.9. Finished ...........................................35
5.7. Application Data Protocol .................................36
6. Cryptographic Computations .....................................36
6.1. Asymmetric Cryptographic Computations .....................36
6.1.1. RSA ................................................36
6.1.2. Diffie-Hellman .....................................37
6.1.3. FORTEZZA ...........................................37
6.2. Symmetric Cryptographic Calculations and the CipherSpec ...37
6.2.1. The Master Secret ..................................37
6.2.2. Converting the Master Secret into Keys and
MAC Secrets ........................................37
7. Security Considerations ........................................39
8. Informative References .........................................40
Appendix A. Protocol Constant Values ..............................42
A.1. Record Layer ...............................................42
A.2. Change Cipher Specs Message ................................43
A.3. Alert Messages .............................................43
A.4. Handshake Protocol .........................................44
A.4.1. Hello Messages .........................................44
A.4.2. Server Authentication and Key Exchange Messages ........45
A.5. Client Authentication and Key Exchange Messages ............46
A.5.1. Handshake Finalization Message .........................47
A.6. The CipherSuite ............................................47
A.7. The CipherSpec .............................................49
Appendix B. Glossary ..............................................50
Appendix C. CipherSuite Definitions ...............................53
Appendix D. Implementation Notes ..................................56
D.1. Temporary RSA Keys .........................................56
D.2. Random Number Generation and Seeding .......................56
D.3. Certificates and Authentication ............................57
D.4. CipherSuites ...............................................57
D.5. FORTEZZA ...................................................57
D.5.1. Notes on Use of FORTEZZA Hardware ......................57
D.5.2. FORTEZZA Cipher Suites .................................58
D.5.3. FORTEZZA Session Resumption ............................58
Appendix E. Version 2.0 Backward Compatibility ....................59
E.1. Version 2 Client Hello .....................................59
E.2. Avoiding Man-in-the-Middle Version Rollback ..............61
Appendix F. Security Analysis .....................................61
F.1. Handshake Protocol .........................................61
F.1.1. Authentication and Key Exchange ........................61
F.1.2. Version Rollback Attacks ...............................64
F.1.3. Detecting Attacks against the Handshake Protocol .......64
F.1.4. Resuming Sessions ......................................65
F.1.5. MD5 and SHA ............................................65
F.2. Protecting Application Data ................................65
F.3. Final Notes ................................................66
Appendix G. Acknowledgements ......................................66
G.1. Other Contributors .........................................66
G.2. Early Reviewers ............................................67
Appendix A. Protocol Constant Values ..............................42
A.1. Record Layer ...............................................42
A.2. Change Cipher Specs Message ................................43
A.3. Alert Messages .............................................43
A.4. Handshake Protocol .........................................44
A.4.1. Hello Messages .........................................44
A.4.2. Server Authentication and Key Exchange Messages ........45
A.5. Client Authentication and Key Exchange Messages ............46
A.5.1. Handshake Finalization Message .........................47
A.6. The CipherSuite ............................................47
A.7. The CipherSpec .............................................49
Appendix B. Glossary ..............................................50
Appendix C. CipherSuite Definitions ...............................53
Appendix D. Implementation Notes ..................................56
D.1. Temporary RSA Keys .........................................56
D.2. Random Number Generation and Seeding .......................56
D.3. Certificates and Authentication ............................57
D.4. CipherSuites ...............................................57
D.5. FORTEZZA ...................................................57
D.5.1. Notes on Use of FORTEZZA Hardware ......................57
D.5.2. FORTEZZA Cipher Suites .................................58
D.5.3. FORTEZZA Session Resumption ............................58
Appendix E. Version 2.0 Backward Compatibility ....................59
E.1. Version 2 Client Hello .....................................59
E.2. Avoiding Man-in-the-Middle Version Rollback ..............61
Appendix F. Security Analysis .....................................61
F.1. Handshake Protocol .........................................61
F.1.1. Authentication and Key Exchange ........................61
F.1.2. Version Rollback Attacks ...............................64
F.1.3. Detecting Attacks against the Handshake Protocol .......64
F.1.4. Resuming Sessions ......................................65
F.1.5. MD5 and SHA ............................................65
F.2. Protecting Application Data ................................65
F.3. Final Notes ................................................66
Appendix G. Acknowledgements ......................................66
G.1. Other Contributors .........................................66
G.2. Early Reviewers ............................................67
The primary goal of the SSL protocol is to provide privacy and reliability between two communicating applications. The protocol is composed of two layers. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [RFC0793]), is the SSL record protocol. The SSL record protocol is used for encapsulation of various higher level protocols. One such encapsulated protocol, the SSL 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. One advantage of SSL is that it is application protocol independent. A higher level protocol can layer on top of the SSL protocol transparently. The SSL protocol provides connection security that has three basic properties:
SSL协议的主要目标是在两个通信应用程序之间提供隐私和可靠性。该协议由两层组成。在最底层，在一些可靠的传输协议（例如TCP[RFC0793]）之上是SSL记录协议。SSL记录协议用于封装各种更高级别的协议。其中一种封装协议，即SSL握手协议，允许服务器和客户端在应用协议传输或接收其第一字节数据之前相互验证并协商加密算法和加密密钥。SSL的一个优点是它独立于应用程序协议。更高级别的协议可以透明地在SSL协议之上分层。SSL协议提供具有三个基本属性的连接安全性：
o The connection is private. Encryption is used after an initial handshake to define a secret key. Symmetric cryptography is used for data encryption (e.g., DES [DES], 3DES [3DES], RC4 [SCH]).
o 连接是私有的。在初始握手后使用加密来定义密钥。对称加密用于数据加密（例如DES[DES]、3DES[3DES]、RC4[SCH]）。
o The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS]).
o 对等方的身份可以使用非对称或公钥加密（例如RSA[RSA]，DSS[DSS]）进行身份验证。
o The connection is reliable. Message transport includes a message integrity check using a keyed Message Authentication Code (MAC) [RFC2104]. Secure hash functions (e.g., SHA, MD5) are used for MAC computations.
o 连接可靠。消息传输包括使用密钥消息认证码（MAC）[RFC2104]的消息完整性检查。安全散列函数（如SHA、MD5）用于MAC计算。
The goals of SSL protocol version 3.0, in order of their priority, are:
SSL协议3.0版的目标（按优先级排列）是：
1. Cryptographic security
1. 密码安全
SSL should be used to establish a secure connection between two parties.
应使用SSL在双方之间建立安全连接。
2. Interoperability
2. 互操作性
Independent programmers should be able to develop applications utilizing SSL 3.0 that will then be able to successfully exchange cryptographic parameters without knowledge of one another's code.
独立程序员应该能够利用SSL 3.0开发应用程序，然后能够在不知道彼此代码的情况下成功地交换加密参数。
Note: It is not the case that all instances of SSL (even in the same application domain) will be able to successfully connect. For instance, if the server supports a particular hardware token, and the client does not have access to such a token, then the connection will not succeed.
注意：并非所有SSL实例（即使在同一应用程序域中）都能够成功连接。例如，如果服务器支持一个特定的硬件令牌，而客户端无权访问该令牌，那么连接将不会成功。
3. Extensibility
3. 扩展性
SSL 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: to prevent the need to create a new protocol (and risking the introduction of possible new weaknesses) and to avoid the need to implement an entire new security library.
SSL试图提供一个框架，在必要时可以将新的公钥和批量加密方法合并到该框架中。这还将实现两个次级目标：防止需要创建新协议（并有可能引入新的弱点）和避免需要实现整个新的安全库。
4. Relative efficiency
4. 相对效率
Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the SSL 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.
加密操作往往是CPU密集型的，尤其是公钥操作。因此，SSL协议包含了可选的会话缓存方案，以减少需要从头开始建立的连接数。此外，还注意减少网络活动。
The SSL protocol version 3.0 specification is intended primarily for readers who will be implementing the protocol and those doing cryptographic analysis of it. The spec 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.
SSL协议3.0版规范主要面向将要实现该协议的读者以及对其进行加密分析的读者。编写规范时就考虑到了这一点，旨在反映这两个群体的需求。因此，许多依赖于算法的数据结构和规则都包含在正文中（而不是附录中），从而更容易访问它们。
This document is not intended to supply any details of service definition or 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 External Data Representation (XDR) [RFC1832] in both its syntax and intent, it
本文档处理外部表示中的数据格式。将使用以下非常基本且随意定义的表示语法。该语法从其结构中的多个源中提取。尽管它在语法和外部数据表示（XDR）[RFC1832]上都与编程语言“C”相似，但它
would be risky to draw too many parallels. The purpose of this presentation language is to document SSL only, not to have general application beyond that particular goal.
太多的类比是有风险的。这种表示语言的目的是仅记录SSL，而不是在特定目标之外具有一般应用程序。
The representation of all data items is explicitly specified. The basic data block size is one byte (i.e., 8 bits). Multiple byte data items are concatenations of bytes, from left to right, from top to bottom. From the byte stream, a multi-byte item (a numeric in the example) is formed (using C notation) by:
明确指定了所有数据项的表示形式。基本数据块大小为一个字节（即8位）。多字节数据项是从左到右、从上到下的字节串联。从字节流中，多字节项（示例中为数字）通过以下方式形成（使用C表示法）：
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ...
| byte[n-1];
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ...
| byte[n-1];
This byte ordering for multi-byte values is the commonplace network byte order or big-endian format.
多字节值的字节顺序是常见的网络字节顺序或big-endian格式。
Comments begin with "/*" and end with "*/". Optional components are denoted by enclosing them in "[[ ]]" double brackets. Single-byte entities containing uninterpreted data are of type opaque.
注释以“/*”开头，以“*/”结尾。可选组件用“[]]”双括号括起来表示。包含未解释数据的单字节实体属于不透明类型。
A vector (single dimensioned array) is a stream of homogeneous data elements. The size of the vector may be specified at documentation time or left unspecified until runtime. In either case, the length declares the number of bytes, not the number of elements, in the vector. The syntax for specifying a new type T' that is a fixed-length vector of type T is
向量（一维数组）是同质数据元素的流。向量的大小可以在文档编制时指定，也可以在运行时才指定。在任何一种情况下，长度都声明向量中的字节数，而不是元素数。指定新类型T'的语法为
T T'[n];
T′[n]；
Here, T' occupies n bytes in the data stream, where n is a multiple of the size of T. The length of the vector is not included in the encoded stream.
这里，T'在数据流中占据n个字节，其中n是T的大小的倍数。矢量的长度不包括在编码流中。
In the following example, Datum is defined to be three consecutive bytes that the protocol does not interpret, while Data is three consecutive Datum, consuming a total of nine bytes.
在下面的示例中，数据被定义为协议不解释的三个连续字节，而数据是三个连续的数据，总共消耗九个字节。
opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* 3 consecutive 3 byte vectors */
opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* 3 consecutive 3 byte vectors */
Variable-length vectors are defined by specifying a subrange of legal lengths, inclusively, using the notation <floor..ceiling>. When encoded, the actual length precedes the vector's contents in the byte stream. The length will be in the form of a number consuming as many bytes as required to hold the vector's specified maximum (ceiling) length. A variable-length vector with an actual length field of zero is referred to as an empty vector.
可变长度向量是通过指定合法长度的子范围来定义的，包括使用符号<floor..天花>。编码时，实际长度先于字节流中向量的内容。长度将以一个数字的形式出现，该数字消耗的字节数与保持向量指定的最大（上限）长度所需的字节数相同。实际长度字段为零的可变长度向量称为空向量。
T T'<floor..ceiling>;
T T'<floor..ceiling>;
In the following example, mandatory is a vector that must contain between 300 and 400 bytes of type opaque. It can never be empty. The actual length field consumes two bytes, a uint16, 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.
在下面的示例中，强制是一个必须包含300到400字节类型不透明的向量。它永远不会是空的。实际长度字段消耗两个字节，一个uint16，足以表示值400（参见第4.4节）。另一方面，longer可以表示多达800字节的数据或400个uint16元素，并且它可能是空的。它的编码将包括一个在向量前面的两字节实际长度字段。
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];
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;
Optionally, one may 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 using 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;
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;
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 5.1).
数字签名、流密码加密、分组密码加密和公钥加密这四种加密操作分别指定为数字签名、流密码、分组密码和公钥加密。字段的加密处理是通过在字段的类型规范之前添加适当的关键字指定来指定的。加密密钥由当前会话状态暗示（参见第5.1节）。
In digital signing, one-way hash functions are used as input for a signing algorithm. In RSA signing, a 36-byte structure of two hashes (one SHA and one MD5) is signed (encrypted with the private key). In DSS, the 20 bytes of the SHA hash are run directly through the Digital Signature Algorithm with no additional hashing.
在数字签名中，单向散列函数用作签名算法的输入。在RSA签名中，对两个哈希（一个SHA和一个MD5）组成的36字节结构进行签名（用私钥加密）。在DSS中，SHA散列的20个字节直接通过数字签名算法运行，无需额外的散列。
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. Because it is unlikely that the plaintext (whatever data is to be sent) will break neatly into the necessary block size (usually 64 bits), it is necessary to pad out the end of short blocks with some regular pattern, usually all zeroes.
在分组密码加密中，每个明文块加密为一个密文块。因为明文（无论要发送什么数据）不太可能整齐地分割成必要的块大小（通常为64位），所以有必要用一些规则模式（通常为全零）填充短块的末尾。
In public key encryption, one-way functions with secret "trapdoors" are used to encrypt the outgoing data. Data encrypted with the public key of a given key pair can only be decrypted with the private key, and vice versa. 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, then the entire structure is encrypted with a stream cipher.
哈希的内容用作签名算法的输入，然后使用流密码对整个结构进行加密。
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;
For example,
struct {
uint8 f1;
uint8 f2;
} Example1;
Example1 ex1 = {1, 4};/* assigns f1 = 1, f2 = 4 */
Example1 ex1 = {1, 4};/* assigns f1 = 1, f2 = 4 */
SSL is a layered protocol. At each layer, messages may include fields for length, description, and content. SSL 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, and reassembled, then delivered to higher level clients.
SSL是一种分层协议。在每一层，消息可能包括长度、描述和内容字段。SSL接收要传输的消息，将数据分割成可管理的块，有选择地压缩数据，应用MAC，加密并传输结果。接收到的数据经过解密、验证、解压缩和重新组装，然后发送到更高级别的客户端。
An SSL session is stateful. It is the responsibility of the SSL handshake protocol to coordinate the states of the client and server, thereby allowing the protocol state machines of each to operate consistently, despite the fact that the state is not exactly parallel. Logically, the state is represented twice, once as the current operating state and (during the handshake protocol) again as the pending state. Additionally, separate read and write states are maintained. When the client or server receives a change cipher spec message, it copies the pending read state into the current read state. When the client or server sends a change cipher spec message, it copies the pending write state into the current write state. When the handshake negotiation is complete, the client and server exchange change cipher spec messages (see Section 5.3), and they then communicate using the newly agreed-upon cipher spec.
SSL会话是有状态的。SSL握手协议负责协调客户端和服务器的状态，从而允许每个客户端和服务器的协议状态机一致运行，尽管状态并不完全平行。从逻辑上讲，状态被表示两次，一次是当前操作状态，一次是挂起状态（在握手协议期间）。此外，还保持单独的读取和写入状态。当客户端或服务器收到更改密码规范消息时，它会将挂起的读取状态复制到当前的读取状态。当客户端或服务器发送更改密码规范消息时，它会将挂起的写入状态复制到当前写入状态。握手协商完成后，客户端和服务器交换密码规范消息（参见第5.3节），然后使用新商定的密码规范进行通信。
An SSL session may include multiple secure connections; in addition, parties may have multiple simultaneous sessions.
SSL会话可以包括多个安全连接；此外，缔约方可同时举行多次会议。
The session state includes the following elements:
会话状态包括以下元素：
session identifier: An arbitrary byte sequence chosen by the server to identify an active or resumable session state.
会话标识符：服务器选择的用于标识活动或可恢复会话状态的任意字节序列。
peer certificate: X509.v3 [X509] certificate of the peer. This element of the state may be null.
对等证书：X509.v3[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.7 for formal definition.)
密码规范：指定批量数据加密算法（如null、DES等）和MAC算法（如MD5或SHA）。它还定义加密属性，如哈希值大小。（正式定义见附录A.7。）
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.
可恢复：指示会话是否可用于启动新连接的标志。
The connection state includes the following elements:
连接状态包括以下元素：
server and client random: Byte sequences that are chosen by the server and client for each connection.
服务器和客户端随机：服务器和客户端为每个连接选择的字节序列。
server write MAC secret: The secret used in MAC operations on data written by the server.
服务器写入MAC机密：在对服务器写入的数据进行MAC操作时使用的机密。
client write MAC secret: The secret used in MAC operations on data written by the client.
客户端写入MAC机密：在对客户端写入的数据进行MAC操作时使用的机密。
server write key: The bulk cipher key for data encrypted by the server and decrypted by the client.
服务器写入密钥：由服务器加密并由客户端解密的数据的批量密码密钥。
client write key: The bulk cipher key for data encrypted by the client and decrypted by the server.
客户端写入密钥：由客户端加密并由服务器解密的数据的批量密码密钥。
initialization vectors: When a block cipher in Cipher Block Chaining (CBC) mode is used, an initialization vector (IV) is maintained for each key. This field is first initialized by the SSL handshake protocol. Thereafter, the final ciphertext block from each record is preserved for use with the following record.
初始化向量：当使用密码块链接（CBC）模式下的块密码时，为每个密钥保留一个初始化向量（IV）。此字段首先由SSL握手协议初始化。此后，每个记录的最后一个密文块将被保留，以便与下面的记录一起使用。
sequence numbers: Each party maintains separate sequence numbers for transmitted and received messages for each connection. When a party sends or receives a change cipher spec message, the appropriate sequence number is set to zero. Sequence numbers are of type uint64 and may not exceed 2^64-1.
序列号：各方为每个连接的发送和接收消息维护单独的序列号。当一方发送或接收更改密码规范消息时，相应的序列号设置为零。序列号为uint64类型，不得超过2^64-1。
The SSL record layer receives uninterpreted data from higher layers in non-empty blocks of arbitrary size.
SSL记录层在任意大小的非空块中接收来自更高层的未解释数据。
The record layer fragments information blocks into SSLPlaintext records 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 SSLPlaintext record).
记录层将信息块分割成2^14字节或更少的SSLPlaintext记录。客户端消息边界不保留在记录层中（即，相同ContentType的多个客户端消息可合并为单个SSLPlaintext记录）。
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[SSLPlaintext.length];
} SSLPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[SSLPlaintext.length];
} SSLPlaintext;
type: The higher level protocol used to process the enclosed fragment.
类型：用于处理封闭片段的更高级别协议。
version: The version of protocol being employed. This document describes SSL version 3.0 (see Appendix A.1).
版本：使用的协议版本。本文件描述了SSL版本3.0（见附录A.1）。
length: The length (in bytes) of the following SSLPlaintext.fragment. The length should not exceed 2^14.
长度：以下SSLPlaintext.fragment的长度（以字节为单位）。长度不应超过2^14。
fragment: The application data. This data is transparent and treated as an independent block to be dealt with by the higher level protocol specified by the type field.
片段：应用程序数据。此数据是透明的，并被视为独立的块，由类型字段指定的更高级别协议处理。
Note: Data of different SSL record layer content types may be interleaved. Application data is generally of lower precedence for transmission than other content types.
注意：不同SSL记录层内容类型的数据可能是交叉的。应用程序数据的传输优先级通常低于其他内容类型。
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 an SSLPlaintext structure into an SSLCompressed structure. Compression functions erase their state information whenever the CipherSpec is replaced.
使用当前会话状态中定义的压缩算法压缩所有记录。总是有一个主动的压缩算法；但是，最初它被定义为CompressionMethod.null。压缩算法将SSLPlaintext结构转换为SSLCompressed结构。每当更换CipherSpec时，压缩函数都会擦除其状态信息。
Note: The CipherSpec is part of the session state described in Section 5.1. References to fields of the CipherSpec are made throughout this document using presentation syntax. A more complete description of the CipherSpec is shown in Appendix A.7.
注意：CipherSpec是第5.1节中描述的会话状态的一部分。本文档使用表示语法对CipherSpec字段进行了引用。附录A.7中给出了CipherSpec的更完整描述。
Compression must be lossless and may not increase the content length by more than 1024 bytes. If the decompression function encounters an SSLCompressed.fragment that would decompress to a length in excess of 2^14 bytes, it should issue a fatal decompression_failure alert (Section 5.4.2).
压缩必须是无损的，并且不能将内容长度增加1024字节以上。如果解压函数遇到一个SSLCompressed.fragment，它将解压到超过2^14字节的长度，它将发出致命的解压失败警报（第5.4.2节）。
struct {
ContentType type; /* same as SSLPlaintext.type */
ProtocolVersion version;/* same as SSLPlaintext.version */
uint16 length;
opaque fragment[SSLCompressed.length];
} SSLCompressed;
struct {
ContentType type; /* same as SSLPlaintext.type */
ProtocolVersion version;/* same as SSLPlaintext.version */
uint16 length;
opaque fragment[SSLCompressed.length];
} SSLCompressed;
length: The length (in bytes) of the following SSLCompressed.fragment. The length should not exceed 2^14 + 1024.
长度：以下SSLCompressed.fragment的长度（字节）。长度不应超过2^14+1024。
fragment: The compressed form of SSLPlaintext.fragment.
fragment:SSLPlaintext.fragment的压缩形式。
Note: A CompressionMethod.null operation is an identity operation; no fields are altered (see Appendix A.4.1.)
注意：CompressionMethod.null操作是标识操作；未更改任何字段（见附录A.4.1.）
Implementation note: Decompression functions are responsible for ensuring that messages cannot cause internal buffer overflows.
实现说明：解压缩功能负责确保消息不会导致内部缓冲区溢出。
All records are protected using the encryption and MAC algorithms defined in the current CipherSpec. There is always an active CipherSpec; however, initially it is SSL_NULL_WITH_NULL_NULL, which does not provide any security.
使用当前CipherSpec中定义的加密和MAC算法保护所有记录。始终存在一个活动的CipherSpec；然而，最初它是SSL\u NULL\u WITH\u NULL\u NULL，它不提供任何安全性。
Once the handshake is complete, the two parties have shared secrets that are used to encrypt records and compute keyed Message Authentication Codes (MACs) on their contents. The techniques used to perform the encryption and MAC operations are defined by the CipherSpec and constrained by CipherSpec.cipher_type. The encryption and MAC functions translate an SSLCompressed structure into an SSLCiphertext. The decryption functions reverse the process. Transmissions also include a sequence number so that missing, altered, or extra messages are detectable.
一旦握手完成，双方就拥有了用于加密记录和计算其内容上的密钥消息身份验证码（MAC）的共享秘密。用于执行加密和MAC操作的技术由CipherSpec定义，并受CipherSpec.cipher_类型的约束。加密和MAC功能将SSLCompressed结构转换为SSLCiphertext。解密函数会反转此过程。传输还包括序列号，以便可以检测到丢失、更改或额外的消息。
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} SSLCiphertext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} SSLCiphertext;
type: The type field is identical to SSLCompressed.type.
类型：类型字段与SSLCompressed.type相同。
version: The version field is identical to SSLCompressed.version.
版本：版本字段与SSLCompressed.version相同。
length: The length (in bytes) of the following SSLCiphertext.fragment. The length may not exceed 2^14 + 2048.
长度：以下SSLCiphertext.fragment的长度（以字节为单位）。长度不得超过2^14+2048。
fragment: The encrypted form of SSLCompressed.fragment, including the MAC.
fragment:SSLCompressed.fragment的加密形式，包括MAC。
Stream ciphers (including BulkCipherAlgorithm.null; see Appendix A.7) convert SSLCompressed.fragment structures to and from stream SSLCiphertext.fragment structures.
流密码（包括BulkCipherGorithm.null；参见附录A.7）将SSLCompressed.fragment结构转换为流SSLCiphertext.fragment结构，并将其转换为流SSLCiphertext.fragment结构。
stream-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
stream-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
The MAC is generated as:
MAC生成为：
hash(MAC_write_secret + pad_2 +
hash(MAC_write_secret + pad_1 + seq_num +
SSLCompressed.type + SSLCompressed.length +
SSLCompressed.fragment));
hash(MAC_write_secret + pad_2 +
hash(MAC_write_secret + pad_1 + seq_num +
SSLCompressed.type + SSLCompressed.length +
SSLCompressed.fragment));
where "+" denotes concatenation.
其中“+”表示串联。
pad_1: The character 0x36 repeated 48 times for MD5 or 40 times for SHA.
pad_1:字符0x36对MD5重复48次，对SHA重复40次。
pad_2: The character 0x5c repeated 48 times for MD5 or 40 times for SHA.
pad_2：字符0x5c对MD5重复48次，对SHA重复40次。
seq_num: The sequence number for this message.
seq_num：此消息的序列号。
hash: Hashing algorithm derived from the cipher suite.
哈希：源自密码套件的哈希算法。
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 SSL_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). SSLCiphertext.length is SSLCompressed.length plus CipherSpec.hash_size.
请注意，MAC是在加密之前计算的。流密码加密整个块，包括MAC。对于不使用同步向量（如RC4）的流密码，一条记录末尾的流密码状态仅用于后续数据包。如果密码套件为SSL\u NULL\u WITH\u NULL\u NULL，则加密包括标识操作（即，数据未加密，MAC大小为零，表示未使用MAC）。SSLCiphertext.length是SSLCompressed.length加上CipherSpec.hash\u大小。
For block ciphers (such as RC2 or DES), the encryption and MAC functions convert SSLCompressed.fragment structures to and from block SSLCiphertext.fragment structures.
对于块密码（如RC2或DES），加密和MAC函数将SSLCompressed.fragment结构与块SSLCiphertext.fragment结构进行转换。
block-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
block-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
The MAC is generated as described in Section 5.2.3.1.
MAC的生成如第5.2.3.1节所述。
padding: Padding that is added to force the length of the plaintext to be a multiple of the block cipher's block length.
填充：添加的填充，用于强制明文长度为分组密码的块长度的倍数。
padding_length: The length of the padding must be less than the cipher's block length and may be zero. The padding length should be such that the total size of the GenericBlockCipher structure is a multiple of the cipher's block length.
padding_length：填充的长度必须小于密码的块长度，并且可以为零。填充长度应确保GenericBlockCipher结构的总大小是密码块长度的倍数。
The encrypted data length (SSLCiphertext.length) is one more than the sum of SSLCompressed.length, CipherSpec.hash_size, and padding_length.
加密数据长度（SSLCiphertext.length）比SSLCompressed.length、CipherSpec.hash_大小和padding_长度之和大一倍。
Note: With CBC, the initialization vector (IV) for the first record is provided by the handshake protocol. The IV for subsequent records is the last ciphertext block from the previous record.
注意：对于CBC，第一条记录的初始化向量（IV）由握手协议提供。后续记录的IV是前一记录的最后一个密文块。
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) CipherSpec. The message consists of a single byte of value 1.
change cipher spec协议存在于加密策略的信号转换中。该协议由单个消息组成，该消息在当前（而不是挂起的）CipherSpec下进行加密和压缩。该消息由值为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 server to notify the receiving party that subsequent records will be protected under the just-negotiated CipherSpec and keys. Reception of this message causes the receiver to copy the read pending state into the read current state. The client sends a change cipher spec message following handshake key exchange and certificate verify messages (if any), and the server sends one after successfully processing the key exchange message it received from the client. An unexpected change cipher spec message should generate an unexpected_message alert (Section 5.4.2). When resuming a previous session, the change cipher spec message is sent after the hello messages.
更改密码规范消息由客户端和服务器发送，以通知接收方后续记录将受到刚刚协商的密码规范和密钥的保护。接收到此消息后，接收器将读取挂起状态复制到读取当前状态。客户端在握手密钥交换和证书验证消息（如果有）之后发送更改密码规范消息，服务器在成功处理从客户端接收到的密钥交换消息后发送更改密码规范消息。意外更改密码规范消息应生成意外消息警报（第5.4.2节）。恢复上一个会话时，在hello消息之后发送change cipher spec消息。
One of the content types supported by the SSL 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.
SSL记录层支持的内容类型之一是警报类型。警报消息传达消息的严重性和警报的说明。具有致命级别的警报消息会导致连接立即终止。在这种情况下，与会话相对应的其他连接可能会继续，但会话标识符必须无效，以防止失败的会话用于建立新连接。与其他消息一样，警报消息按照当前连接状态进行加密和压缩。
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),
decompression_failure(30),
handshake_failure(40),
no_certificate(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter (47)
(255)
} AlertDescription;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decompression_failure(30),
handshake_failure(40),
no_certificate(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter (47)
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. 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. The session becomes unresumable if any connection is terminated without proper close_notify messages with level equal to warning.
close_notify：此消息通知收件人发件人将不再在此连接上发送任何消息。如果任何连接在未正确关闭的情况下终止，会话将变得不可恢复。通知级别等于警告。
Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored.
任何一方均可通过发送关闭通知警报启动关闭。关闭警报后收到的任何数据都将被忽略。
Each party is required to send a close_notify alert before closing the write side of the connection. It is required that the other party 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警报，并立即关闭连接，丢弃任何挂起的写入。关闭的发起人不需要在关闭连接的读取端之前等待响应的关闭通知警报。
NB: It is assumed that closing a connection reliably delivers pending data before destroying the transport.
注意：假设在破坏传输之前，关闭连接可以可靠地传递挂起的数据。
Error handling in the SSL 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 are required to forget any session identifiers, keys, and secrets associated with a failed connection. The following error alerts are defined:
SSL握手协议中的错误处理非常简单。当检测到错误时，检测方向另一方发送消息。在传输或接收到致命警报消息后，双方立即关闭连接。服务器和客户端需要忘记与失败连接相关的任何会话标识符、密钥和机密。定义了以下错误警报：
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 message is always fatal.
bad_record_mac：如果接收到的记录的mac不正确，将返回此警报。这个消息总是致命的。
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: A no_certificate alert message may be sent in response to a certification request if no appropriate certificate is available.
无证书：如果没有合适的证书可用，则可能会发送无证书警报消息以响应证书请求。
bad_certificate: A certificate was corrupt, contained signatures that did not verify correctly, etc.
坏证书：证书已损坏，包含未正确验证的签名等。
unsupported_certificate: A certificate was of an unsupported type.
不支持的\u证书：证书的类型不受支持。
certificate_revoked: A certificate was revoked by its signer.
证书被吊销：证书已被其签名者吊销。
certificate_expired: A certificate has expired or is not currently valid.
证书\u过期：证书已过期或当前无效。
certificate_unknown: Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable.
证书\u未知：处理证书时出现其他一些（未指定）问题，使其无法接受。
illegal_parameter: A field in the handshake was out of range or inconsistent with other fields. This is always fatal.
非法参数：握手中的字段超出范围或与其他字段不一致。这总是致命的。
The cryptographic parameters of the session state are produced by the SSL handshake protocol, which operates on top of the SSL record layer. When an SSL 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. These processes are performed in 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.
会话状态的加密参数由SSL握手协议生成，该协议在SSL记录层上运行。当SSL客户端和服务器第一次开始通信时，它们就协议版本达成一致，选择加密算法，选择性地相互验证，并使用公钥加密技术生成共享机密。这些过程是在握手协议中执行的，可以总结如下：客户端发送一条客户端hello消息，服务器必须用服务器hello消息响应该消息，否则将发生致命错误，连接将失败。客户端hello和服务器hello用于在客户端和服务器之间建立安全增强功能。客户端hello和服务器hello建立以下属性：协议版本、会话ID、密码套件和压缩方法。此外，还会生成并交换两个随机值：ClientHello.random和ServerHello.random。
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 their 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. Now 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 either the certificate message or a no_certificate alert. 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-signed certificate verify message is sent to explicitly verify the certificate.
在hello消息之后，服务器将发送其证书（如果要对其进行身份验证）。此外，如果需要，可以发送服务器密钥交换消息（例如，如果其服务器没有证书，或者其证书仅用于签名）。如果服务器经过身份验证，它可能会从客户端请求证书（如果该证书适用于所选的密码套件）。现在，服务器将发送服务器hello done消息，指示握手的hello消息阶段已完成。然后，服务器将等待客户端响应。如果服务器已发送证书请求消息，则客户端必须发送证书消息或无证书警报。现在发送客户机密钥交换消息，该消息的内容将取决于在客户机hello和服务器hello之间选择的公钥算法。如果客户端已发送具有签名功能的证书，则会发送数字签名证书验证消息以显式验证证书。
At this point, a change cipher spec message is sent by the client, and the client copies the pending CipherSpec into the current CipherSpec. 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 CipherSpec, and send its finished message under the new CipherSpec. At this point, the handshake is complete and the client and server may begin to exchange application layer data. (See flow chart below.)
此时，客户机将发送更改密码规范消息，客户机将挂起的CipherSpec复制到当前CipherSpec中。然后，客户机立即根据新算法、密钥和机密发送完成的消息。作为响应，服务器将发送其自己的ChangeCipherSpec消息，将挂起的消息传输到当前CipherSpec，并在新CipherSpec下发送其完成的消息。此时，握手完成，客户机和服务器可以开始交换应用层数据。（见下面的流程图。）
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
* Indicates optional or situation-dependent messages that are not always sent.
* 指示并非始终发送的可选消息或情况相关消息。
Note: To help avoid pipeline stalls, ChangeCipherSpec is an independent SSL protocol content type, and is not actually an SSL handshake message.
注意：为了帮助避免管道暂停，ChangeCipherSpec是一种独立的SSL协议内容类型，实际上不是SSL握手消息。
When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters) the message flow is as follows:
当客户端和服务器决定恢复以前的会话或复制现有会话（而不是协商新的安全参数）时，消息流如下所示：
The client sends a ClientHello using the session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same session ID value. At this point, both client and server must send 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 SSL client and server perform a full handshake.
客户端使用要恢复的会话的会话ID发送ClientHello。然后服务器检查其会话缓存是否匹配。如果找到匹配项，并且服务器愿意在指定的会话状态下重新建立连接，它将发送具有相同会话ID值的ServerHello。此时，客户端和服务器都必须发送更改密码规范消息，并直接处理完成的消息。一旦重建完成，客户端和服务器就可以开始交换应用层数据。（请参阅下面的流程图。）如果找不到会话ID匹配，服务器将生成新的会话ID，SSL客户端和服务器将执行完全握手。
Client Server
客户端服务器
ClientHello -------->
ServerHello
[change cipher spec]
<-------- Finished
change cipher spec
Finished -------->
Application Data <-------> Application Data
ClientHello -------->
ServerHello
[change cipher spec]
<-------- Finished
change cipher spec
Finished -------->
Application Data <-------> Application Data
The contents and significance of each message will be presented in detail in the following sections.
以下各节将详细介绍每条信息的内容和意义。
The SSL handshake protocol is one of the defined higher level clients of the SSL record protocol. This protocol is used to negotiate the secure attributes of a session. Handshake messages are supplied to the SSL record layer, where they are encapsulated within one or more SSLPlaintext structures, which are processed and transmitted as specified by the current active session state.
SSL握手协议是SSL记录协议定义的更高级别客户端之一。此协议用于协商会话的安全属性。握手消息被提供给SSL记录层，在那里它们被封装在一个或多个SSLPlaintext结构中，并按照当前活动会话状态的指定进行处理和传输。
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), (255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} body;
} Handshake;
The handshake protocol messages are presented in the order they must be sent; sending handshake messages in an unexpected order results in a fatal error.
握手协议消息按其必须发送的顺序呈现；以意外顺序发送握手消息会导致致命错误。
The hello phase messages are used to exchange security enhancement capabilities between the client and server. When a new session begins, the CipherSpec encryption, hash, and compression algorithms are initialized to null. The current CipherSpec is used for renegotiation messages.
hello阶段消息用于在客户端和服务器之间交换安全增强功能。新会话开始时，CipherSpec加密、哈希和压缩算法将初始化为null。当前CipherSpec用于重新协商消息。
The hello request message may be sent by the server at any time, but will be ignored by the client if the handshake protocol is already underway. It is a simple notification that the client should begin the negotiation process anew by sending a client hello message when convenient.
hello请求消息可以在任何时候由服务器发送，但如果握手协议已经在进行中，则客户端将忽略该消息。这是一个简单的通知，客户机应该在方便的时候通过发送客户机hello消息重新开始协商过程。
Note: Since handshake messages are intended to have transmission precedence over application data, it is expected that the negotiation begin in no more than one or two times the transmission time of a maximum-length application data message.
注意：由于握手消息的传输优先于应用程序数据，因此预期协商开始时间不超过最大长度应用程序数据消息传输时间的一倍或两倍。
After sending a hello request, servers should not repeat the request until the subsequent handshake negotiation is complete. A client that receives a hello request while in a handshake negotiation state should simply ignore the message.
发送hello请求后，服务器不应重复该请求，直到后续握手协商完成。在握手协商状态下接收hello请求的客户端应该忽略该消息。
The structure of a hello request message is as follows:
hello请求消息的结构如下所示：
struct { } HelloRequest;
struct { } HelloRequest;
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. The client hello message includes a random structure, which is used later in the protocol.
当客户机首次连接到服务器时，需要将客户机hello作为其第一条消息发送。客户机还可以发送客户机hello以响应hello请求，或者主动发送，以便在现有连接中重新协商安全参数。客户机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 according to the sender's internal clock. Clocks are not required to be set correctly by the basic SSL protocol; higher level or application protocols may define additional requirements.
gmt\u unix\u时间：根据发送方的内部时钟以标准unix 32位格式显示的当前时间和日期。基本SSL协议不要求正确设置时钟；更高级别或应用程序协议可能会定义附加要求。
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, this connection, or 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, while the third option makes it possible to establish several simultaneous independent secure connections without repeating the full handshake protocol. The actual contents of the SessionID are defined by the server.
客户机hello消息包括一个可变长度的会话标识符。如果不为空，则该值标识同一客户端和服务器之间的会话，客户端希望重用其安全参数。会话标识符可以来自较早的连接、此连接或另一个当前活动的连接。如果客户机只希望更新连接的随机结构和派生值，则第二个选项很有用，而第三个选项可以在不重复完整握手协议的情况下同时建立多个独立的安全连接。SessionID的实际内容由服务器定义。
opaque SessionID<0..32>;
opaque SessionID<0..32>;
Warning: Servers must not place confidential information in session identifiers or let the contents of fake session identifiers cause any breach of security.
警告：服务器不得在会话标识符中放置机密信息，也不得让虚假会话标识符的内容造成任何安全漏洞。
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 (first choice first). Each CipherSuite defines both a key exchange algorithm and a CipherSpec. The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection.
在客户机hello消息中从客户机传递到服务器的CipherSuite列表包含客户机支持的加密算法组合，按照客户机的首选项顺序排列（首选项优先）。每个密码套件都定义了密钥交换算法和密码规范。服务器将选择密码套件，如果没有可接受的选项，则返回握手失败警报并关闭连接。
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. If the server supports none of those specified by the client, the session must fail.
客户机hello包括客户机支持的压缩算法列表，根据客户机的偏好排序。如果服务器不支持客户端指定的任何一项，则会话必须失败。
enum { null(0), (255) } CompressionMethod;
enum { null(0), (255) } CompressionMethod;
Issue: Which compression methods to support is under investigation.
问题：支持哪种压缩方法正在研究中。
The structure of the client hello is as follows.
客户机hello的结构如下所示。
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 SSL protocol by which the client wishes to communicate during this session. This should be the most recent (highest valued) version supported by the client. For this version of the specification, the version will be 3.0 (see Appendix E for details about backward compatibility).
客户端版本：客户端希望在此会话期间通信的SSL协议版本。这应该是客户端支持的最新（最高值）版本。对于本规范版本，版本为3.0（有关向后兼容性的详细信息，请参见附录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 the client wishes to generate new security parameters.
会话id：客户端希望用于此连接的会话的id。如果没有可用的会话id或客户端希望生成新的安全参数，则此字段应为空。
cipher_suites: This is a list of the cryptographic options supported by the client, sorted 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.6.
cipher_suites：这是客户端支持的加密选项列表，按客户端的第一个首选项排序。如果session_id字段不为空（意味着会话恢复请求），则此向量必须至少包含来自该会话的密码套件。数值在附录A.6中定义。
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), this vector must include at least the compression_method from that session. All implementations must support CompressionMethod.null.
压缩方法：这是客户机支持的压缩方法列表，按客户机首选项排序。如果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请求除外）都被视为致命错误。
Implementation note: Application data may not be sent before a finished message has been sent. Transmitted application data is known to be insecure until a valid finished message has been received. This absolute restriction is relaxed if there is a current, non-null encryption on this connection.
实施说明：在发送完成的消息之前，不能发送应用程序数据。在收到有效的完成消息之前，传输的应用程序数据是不安全的。如果此连接上存在当前的非空加密，则此绝对限制将被放宽。
Forward compatibility note: In the interests of forward compatibility, it is permitted for a client hello message to include extra data after the compression methods. This data must be included in the handshake hashes, but must otherwise be ignored.
前向兼容性注意：为了前向兼容性，允许客户端hello消息在压缩方法之后包含额外数据。此数据必须包含在握手哈希中，否则必须忽略。
The server processes the client hello message and responds with either a handshake_failure alert or server hello message.
服务器处理客户端hello消息，并以握手失败警报或服务器hello消息进行响应。
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 will be 3.0 (see Appendix E for details about backward compatibility).
服务器版本：此字段将包含客户端hello中客户端建议的较低版本和服务器支持的最高版本。对于本规范版本，版本为3.0（有关向后兼容性的详细信息，请参见附录E）。
random: This structure is generated by the server and must be different from (and independent of) 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.
会话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_套件：服务器从ClientHello.cipher_套件中的列表中选择的单个密码套件。对于恢复的会话，此字段是正在恢复的会话状态的值。
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方法列表中选择的单一压缩算法。对于恢复的会话，此字段是恢复的会话状态的值。
If the server is to be authenticated (which is generally the case), the server sends its certificate immediately following the server hello message. The certificate type must be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509.v3 certificate (or a modified X.509 certificate in the case of FORTEZZA(tm) [FOR]). The same message type will be used for the client's response to a certificate request message.
如果要对服务器进行身份验证（通常是这样），服务器会在服务器hello消息之后立即发送其证书。证书类型必须适合所选密码套件的密钥交换算法，并且通常是X.509.v3证书（或者在FORTEZZA（tm）[for]的情况下是经过修改的X.509证书）。客户端对证书请求消息的响应将使用相同的消息类型。
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert certificate_list<1..2^24-1>;
} Certificate;
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert certificate_list<1..2^24-1>;
} Certificate;
certificate_list: This is a sequence (chain) of X.509.v3 certificates, ordered with the sender's certificate first followed by any certificate authority certificates proceeding sequentially upward.
证书列表：这是X.509.v3证书的序列（链），排序时首先是发送者的证书，然后是按顺序向上的证书颁发机构证书。
Note: PKCS #7 [PKCS7] is not used as the format for the certificate vector because PKCS #6 [PKCS6] extended certificates are not used. Also, PKCS #7 defines a Set rather than a Sequence, making the task of parsing the list more difficult.
注意：PKCS#7[PKCS7]未用作证书向量的格式，因为未使用PKCS#6[PKCS6]扩展证书。此外，PKCS#7定义了一个集合而不是一个序列，这使得解析列表的任务更加困难。
The server key exchange message is sent by the server if it has no certificate, has a certificate only used for signing (e.g., DSS [DSS] certificates, signing-only RSA [RSA] certificates), or FORTEZZA KEA key exchange is used. This message is not used if the server certificate contains Diffie-Hellman [DH1] parameters.
如果服务器没有证书、只有用于签名的证书（例如，DSS[DSS]证书、仅签名RSA[RSA]证书）或使用FORTEZZA KEA密钥交换，则服务器将发送服务器密钥交换消息。如果服务器证书包含Diffie Hellman[DH1]参数，则不使用此消息。
Note: According to current US export law, RSA moduli larger than 512 bits may not be used for key exchange in software exported from the US. With this message, larger RSA keys may be used as signature-only certificates to sign temporary shorter RSA keys for key exchange.
注：根据美国现行出口法，在从美国出口的软件中，大于512位的RSA模不可用于密钥交换。通过此消息，可以将较大的RSA密钥用作仅签名证书，以签名用于密钥交换的临时较短RSA密钥。
enum { rsa, diffie_hellman, fortezza_kea }
KeyExchangeAlgorithm;
enum { rsa, diffie_hellman, fortezza_kea }
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_模数：服务器临时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 (gX mod p).
dh_Ys：服务器的Diffie-Hellman公共值（gX mod p）。
struct {
opaque r_s [128];
} ServerFortezzaParams;
struct {
opaque r_s [128];
} ServerFortezzaParams;
r_s: Server random number for FORTEZZA KEA (Key Exchange Algorithm).
r_s:FORTEZZA KEA（密钥交换算法）的服务器随机数。
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
case fortezza_kea:
ServerFortezzaParams params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
case fortezza_kea:
ServerFortezzaParams params;
};
} ServerKeyExchange;
params: The server's key exchange parameters.
params：服务器的密钥交换参数。
signed_params: A hash of the corresponding params value, with the signature appropriate to that hash applied.
signed_params：对应params值的散列，并应用与该散列相应的签名。
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;
digitally-signed struct {
select(SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
opaque md5_hash[16];
opaque sha_hash[20];
case dsa:
opaque sha_hash[20];
};
} Signature;
digitally-signed struct {
select(SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
opaque md5_hash[16];
opaque sha_hash[20];
case dsa:
opaque sha_hash[20];
};
} Signature;
A non-anonymous server can optionally request a certificate from the client, if appropriate for the selected cipher suite.
如果适用于所选密码套件，非匿名服务器可以选择从客户端请求证书。
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(20),
(255)
} ClientCertificateType;
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh(5), dss_ephemeral_dh(6), fortezza_kea(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<3..2^16-1>;
} CertificateRequest;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..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.
证书颁发机构：可接受证书颁发机构的可分辨名称列表。
Note: DistinguishedName is derived from [X509].
注：DifferentiedName源自[X509]。
Note: It is a fatal handshake_failure alert for an anonymous server to request client identification.
注意：匿名服务器请求客户端标识是一个致命的握手失败警报。
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和相关消息的结束。发送此消息后，服务器将等待客户端响应。
struct { } ServerHelloDone;
struct { } ServerHelloDone;
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参数是否可接受。
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 no_certificate alert instead. This alert is only a warning; however, the server may respond with a fatal handshake failure alert if client authentication is required. Client certificates are sent using the certificate defined in Section 5.6.2.
这是客户端在收到服务器hello done消息后可以发送的第一条消息。仅当服务器请求证书时，才会发送此消息。如果没有合适的证书可用，客户端应改为发送无证书警报。此警报只是一个警告；但是，如果需要客户端身份验证，服务器可能会发出致命握手失败警报。使用第5.6.2节中定义的证书发送客户端证书。
Note: Client Diffie-Hellman certificates must match the server specified Diffie-Hellman parameters.
注意：客户端Diffie-Hellman证书必须与服务器指定的Diffie-Hellman参数匹配。
The choice of messages depends on which public key algorithm(s) has (have) been selected. See Section 5.6.3 for the KeyExchangeAlgorithm definition.
消息的选择取决于已选择的公钥算法。有关KeyExchangeAlgorithm的定义，请参见第5.6.3节。
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
case fortezza_kea: FortezzaKeys;
} exchange_keys;
} ClientKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
case fortezza_kea: FortezzaKeys;
} exchange_keys;
} ClientKeyExchange;
The information to select the appropriate record structure is in the pending session state (see Section 5.1).
选择适当记录结构的信息处于挂起会话状态（参见第5.1节）。
If RSA is being used for key agreement and authentication, the client generates a 48-byte premaster secret, encrypts it under the public key from the server's certificate or temporary RSA key from a server key exchange message, and sends the result in an encrypted premaster secret message.
如果RSA用于密钥协商和身份验证，则客户端将生成一个48字节的premaster机密，使用服务器证书中的公钥或服务器密钥交换消息中的临时RSA密钥对其进行加密，并将结果发送到加密的premaster机密消息中。
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.
客户端版本：客户端支持的最新（最新）版本。这用于检测版本回滚攻击。
random: 46 securely-generated random bytes.
随机：46个安全生成的随机字节。
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 6.1.
pre_master_secret：此随机值由客户端生成，用于生成主密钥，如第6.1节所述。
Under FORTEZZA, the client derives a token encryption key (TEK) using the FORTEZZA Key Exchange Algorithm (KEA). The client's KEA calculation uses the public key in the server's certificate along with private parameters in the client's token. The client sends public parameters needed for the server to generate the TEK, using its own private parameters. The client generates session keys, wraps them using the TEK, and sends the results to the server. The client generates IVs for the session keys and TEK and sends them also. The client generates a random 48-byte premaster secret, encrypts it using the TEK, and sends the result:
在FORTEZZA下，客户端使用FORTEZZA密钥交换算法（KEA）派生令牌加密密钥（TEK）。客户端的KEA计算使用服务器证书中的公钥以及客户端令牌中的私有参数。客户端使用自己的私有参数发送服务器生成TEK所需的公共参数。客户端生成会话密钥，使用TEK包装它们，并将结果发送到服务器。客户端为会话密钥和TEK生成IVs，并发送它们。客户端生成一个随机的48字节premaster密码，使用TEK对其进行加密，并发送结果：
struct {
opaque y_c<0..128>;
opaque r_c[128];
opaque y_signature[40];
opaque wrapped_client_write_key[12];
opaque wrapped_server_write_key[12];
opaque client_write_iv[24];
opaque server_write_iv[24];
opaque master_secret_iv[24];
block-ciphered opaque encrypted_pre_master_secret[48];
} FortezzaKeys;
struct {
opaque y_c<0..128>;
opaque r_c[128];
opaque y_signature[40];
opaque wrapped_client_write_key[12];
opaque wrapped_server_write_key[12];
opaque client_write_iv[24];
opaque server_write_iv[24];
opaque master_secret_iv[24];
block-ciphered opaque encrypted_pre_master_secret[48];
} FortezzaKeys;
y_signature: y_signature is the signature of the KEA public key, signed with the client's DSS private key.
y_签名：y_签名是KEA公钥的签名，使用客户端的DSS私钥进行签名。
y_c: The client's Yc value (public key) for the KEA calculation. If the client has sent a certificate, and its KEA public key is suitable, this value must be empty since the certificate already contains this value. If the client sent a certificate without a suitable public key, y_c is used and y_signature is the KEA public key signed with the client's DSS private key. For this value to be used, it must be between 64 and 128 bytes.
y_c：用于KEA计算的客户端Yc值（公钥）。如果客户端已发送证书，且其KEA公钥合适，则此值必须为空，因为证书已包含此值。如果客户端发送的证书没有合适的公钥，则使用y_c，y_签名是使用客户端DSS私钥签名的KEA公钥。要使用此值，它必须介于64和128字节之间。
r_c: The client's Rc value for the KEA calculation.
r_c：客户用于KEA计算的Rc值。
wrapped_client_write_key: This is the client's write key, wrapped by the TEK.
wrapped_client_write_key：这是客户机的写密钥，由TEK包装。
wrapped_server_write_key: This is the server's write key, wrapped by the TEK.
wrapped_server_write_key：这是服务器的写密钥，由TEK包装。
client_write_iv: The IV for the client write key.
client_write_iv：客户端写入密钥的iv。
server_write_iv: The IV for the server write key.
server_write_iv：服务器写入密钥的iv。
master_secret_iv: This is the IV for the TEK used to encrypt the premaster secret.
master_secret_iv：这是用于加密premaster机密的TEK的iv。
pre_master_secret: A random value, generated by the client and used to generate the master secret, as specified in Section 6.1. In the above structure, it is encrypted using the TEK.
pre_master_secret：一个随机值，由客户端生成，用于生成主密钥，如第6.1节所述。在上述结构中，使用TEK对其进行加密。
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.
如果客户机证书中尚未包含Diffie-Hellman公共值（Yc），则此结构将传递该客户机的Diffie-Hellman公共值。Yc使用的编码由枚举的PublicValueEncoding确定。
enum { implicit, explicit } PublicValueEncoding;
enum { implicit, explicit } PublicValueEncoding;
implicit: If the client certificate already contains the public value, then it is implicit and Yc does not need to be sent again.
隐式：如果客户端证书已经包含公共值，那么它是隐式的，并且不需要再次发送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）。
This message is used to provide explicit verification of a client certificate. This message is only sent following any client certificate that has signing capability (i.e., all certificates except those containing fixed Diffie-Hellman parameters).
此消息用于提供客户端证书的显式验证。此消息仅在具有签名功能的任何客户端证书（即除包含固定Diffie-Hellman参数的证书外的所有证书）之后发送。
struct {
Signature signature;
} CertificateVerify;
struct {
Signature signature;
} CertificateVerify;
CertificateVerify.signature.md5_hash
MD5(master_secret + pad_2 +
MD5(handshake_messages + master_secret + pad_1));
Certificate.signature.sha_hash
SHA(master_secret + pad_2 +
SHA(handshake_messages + master_secret + pad_1));
CertificateVerify.signature.md5_hash
MD5(master_secret + pad_2 +
MD5(handshake_messages + master_secret + pad_1));
Certificate.signature.sha_hash
SHA(master_secret + pad_2 +
SHA(handshake_messages + master_secret + pad_1));
pad_1: This is identical to the pad_1 defined in Section 5.2.3.1.
垫1：这与第5.2.3.1节中定义的垫1相同。
pad_2: This is identical to the pad_2 defined in Section 5.2.3.1.
垫2：这与第5.2.3.1节中定义的垫2相同。
Here, handshake_messages refers to all handshake messages starting at client hello up to but not including this message.
在这里，握手_消息指的是从客户机hello开始直到但不包括此消息的所有握手消息。
A finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful. The finished message is the first protected with the just-negotiated algorithms, keys, and secrets. No acknowledgment of the finished message is required; parties may begin sending encrypted data immediately after sending the finished message. Recipients of finished messages must verify that the contents are correct.
完成的消息总是在更改密码规范消息之后立即发送，以验证密钥交换和身份验证过程是否成功。完成的消息是第一个使用刚刚协商的算法、密钥和机密进行保护的消息。不需要确认已完成的消息；各方可以在发送完成的消息后立即开始发送加密数据。完成邮件的收件人必须验证内容是否正确。
enum { client(0x434C4E54), server(0x53525652) } Sender;
enum { client(0x434C4E54), server(0x53525652) } Sender;
struct {
opaque md5_hash[16];
opaque sha_hash[20];
} Finished;
struct {
opaque md5_hash[16];
opaque sha_hash[20];
} Finished;
md5_hash: MD5(master_secret + pad2 + MD5(handshake_messages + Sender
+ master_secret + pad1));
md5_hash: MD5(master_secret + pad2 + MD5(handshake_messages + Sender
+ master_secret + pad1));
sha_hash: SHA(master_secret + pad2 + SHA(handshake_messages + Sender
+ master_secret + pad1));
sha_hash: SHA(master_secret + pad2 + SHA(handshake_messages + Sender
+ master_secret + pad1));
handshake_messages: All of the data from all handshake messages up to but not including this message. This is only data visible at the handshake layer and does not include record layer headers.
握手信息：截至但不包括此信息的所有握手信息中的所有数据。这是握手层上唯一可见的数据，不包括记录层标题。
It is a fatal error if a finished message is not preceeded by a change cipher spec message at the appropriate point in the handshake.
如果在握手的适当位置，完成的消息之前没有更改密码规范消息，则这是一个致命错误。
The hash contained in finished messages sent by the server incorporate Sender.server; those sent by the client incorporate Sender.client. 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 5.6.8 because it would include the certificate verify message (if sent).
服务器发送的已完成邮件中包含的哈希包含Sender.server；客户端发送的邮件包含Sender.client。值handshake_messages包括从客户端hello开始直到但不包括此已完成消息的所有握手消息。这可能不同于第5.6.8节中的握手消息，因为它将包括证书验证消息（如果已发送）。
Note: Change cipher spec messages are not handshake messages and are not included in the hash computations.
注意：更改密码规范消息不是握手消息，不包括在哈希计算中。
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.
应用程序数据消息由记录层承载，并根据当前连接状态进行分段、压缩和加密。消息被视为对记录层透明的数据。
The key exchange, authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the server and revealed in the server hello message.
密钥交换、身份验证、加密和MAC算法由服务器选择并在服务器hello消息中显示的密码套件决定。
The asymmetric algorithms are used in the handshake protocol to authenticate parties and to generate shared keys and secrets.
在握手协议中使用非对称算法对各方进行身份验证，并生成共享密钥和秘密。
For Diffie-Hellman, RSA, and FORTEZZA, 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.
对于Diffie Hellman、RSA和FORTEZZA，使用相同的算法将pre_master_秘密转换为master_秘密。在计算主密钥后，应从内存中删除预主密钥。
master_secret =
MD5(pre_master_secret + SHA('A' + pre_master_secret +
ClientHello.random + ServerHello.random)) +
MD5(pre_master_secret + SHA('BB' + pre_master_secret +
ClientHello.random + ServerHello.random)) +
MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
ClientHello.random + ServerHello.random));
master_secret =
MD5(pre_master_secret + SHA('A' + pre_master_secret +
ClientHello.random + ServerHello.random)) +
MD5(pre_master_secret + SHA('BB' + pre_master_secret +
ClientHello.random + ServerHello.random)) +
MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
ClientHello.random + ServerHello.random));
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.
执行常规的Diffie-Hellman计算。协商密钥（Z）用作pre_master_secret，并转换为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参数由服务器指定，可以是短暂的，也可以包含在服务器的证书中。
A random 48-byte pre_master_secret is sent encrypted under the TEK and its IV. The server decrypts the pre_master_secret and converts it into a master_secret, as specified above. Bulk cipher keys and IVs for encryption are generated by the client's token and exchanged in the key exchange message; the master_secret is only used for MAC computations.
在TEK及其IV下加密发送随机48字节的pre_master_机密。服务器解密pre_master_机密并将其转换为master_机密，如上所述。用于加密的批量加密密钥和IV由客户端令牌生成，并在密钥交换消息中交换；主密钥仅用于MAC计算。
The technique used to encrypt and verify the integrity of SSL records is specified by the currently active CipherSpec. A typical example would be to encrypt data using DES and generate authentication codes using MD5. The encryption and MAC algorithms are set to SSL_NULL_WITH_NULL_NULL at the beginning of the SSL handshake protocol, indicating that no message authentication or encryption is performed. The handshake protocol is used to negotiate a more secure CipherSpec and to generate cryptographic keys.
用于加密和验证SSL记录完整性的技术由当前活动的CipherSpec指定。一个典型的例子是使用DES加密数据，并使用MD5生成身份验证代码。加密和MAC算法在SSL握手协议开始时设置为SSL_NULL_，并带有_NULL_NULL，表示未执行消息身份验证或加密。握手协议用于协商更安全的密码规范并生成加密密钥。
Before secure encryption or integrity verification can be performed on records, the client and server need to generate shared secret information known only to themselves. This value is a 48-byte quantity called the master secret. The master secret is used to generate keys and secrets for encryption and MAC computations. Some algorithms, such as FORTEZZA, may have their own procedure for generating encryption keys (the master secret is used only for MAC computations in FORTEZZA).
在对记录执行安全加密或完整性验证之前，客户端和服务器需要生成只有它们自己知道的共享机密信息。该值是一个48字节的量，称为主密钥。主密钥用于生成用于加密和MAC计算的密钥和密钥。某些算法，如FORTEZZA，可能有自己的生成加密密钥的过程（主密钥仅用于FORTEZZA中的MAC计算）。
The master secret is hashed into a sequence of secure bytes, which are assigned to the MAC secrets, keys, and non-export IVs required by the current CipherSpec (see Appendix A.7). CipherSpecs require a client write MAC secret, a server write MAC secret, a client write key, a server write key, a client write IV, and a server write IV, which are generated from the master secret in that order. Unused
主密钥散列为一系列安全字节，这些字节分配给当前CipherSpec所需的MAC密钥、密钥和非导出IV（见附录a.7）。CipherSpec需要客户机写入MAC密钥、服务器写入MAC密钥、客户机写入密钥、服务器写入密钥、客户机写入IV和服务器写入IV，这些密钥按照主密钥的顺序生成。未使用
values, such as FORTEZZA keys communicated in the KeyExchange message, are empty. The following inputs are available to the key definition process:
值（如KeyExchange消息中传递的FORTEZZA密钥）为空。以下输入可用于密钥定义过程：
opaque MasterSecret[48] ClientHello.random ServerHello.random
不透明MasterSecret[48]ClientHello.random服务器Hello.random
When generating keys and MAC secrets, the master secret is used as an entropy source, and the random values provide unencrypted salt material and IVs for exportable ciphers.
生成密钥和MAC密钥时，主密钥用作熵源，随机值提供未加密的salt材料和可导出密码的IVs。
To generate the key material, compute
要生成关键材质，请计算
key_block =
MD5(master_secret + SHA(`A' + master_secret +
ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA(`BB' + master_secret +
ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA(`CCC' + master_secret +
ServerHello.random +
ClientHello.random)) + [...];
key_block =
MD5(master_secret + SHA(`A' + master_secret +
ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA(`BB' + master_secret +
ServerHello.random +
ClientHello.random)) +
MD5(master_secret + SHA(`CCC' + master_secret +
ServerHello.random +
ClientHello.random)) + [...];
until enough output has been generated. Then, the key_block is partitioned as follows.
直到产生足够的输出。然后，按如下方式对key_块进行分区。
client_write_MAC_secret[CipherSpec.hash_size]
server_write_MAC_secret[CipherSpec.hash_size]
client_write_key[CipherSpec.key_material]
server_write_key[CipherSpec.key_material]
client_write_IV[CipherSpec.IV_size] /* non-export ciphers */
server_write_IV[CipherSpec.IV_size] /* non-export ciphers */
client_write_MAC_secret[CipherSpec.hash_size]
server_write_MAC_secret[CipherSpec.hash_size]
client_write_key[CipherSpec.key_material]
server_write_key[CipherSpec.key_material]
client_write_IV[CipherSpec.IV_size] /* non-export ciphers */
server_write_IV[CipherSpec.IV_size] /* non-export ciphers */
Any extra key_block material is discarded.
任何额外的键块材质都将被丢弃。
Exportable encryption algorithms (for which CipherSpec.is_exportable is true) require additional processing as follows to derive their final write keys:
可导出加密算法（CipherSpec.is_Exportable为true）需要进行以下附加处理，以导出其最终写入密钥：
final_client_write_key = MD5(client_write_key +
ClientHello.random +
ServerHello.random);
final_server_write_key = MD5(server_write_key +
ServerHello.random +
ClientHello.random);
final_client_write_key = MD5(client_write_key +
ClientHello.random +
ServerHello.random);
final_server_write_key = MD5(server_write_key +
ServerHello.random +
ClientHello.random);
Exportable encryption algorithms derive their IVs from the random messages:
可导出的加密算法从随机消息中导出其IVs：
client_write_IV = MD5(ClientHello.random + ServerHello.random);
server_write_IV = MD5(ServerHello.random + ClientHello.random);
client_write_IV = MD5(ClientHello.random + ServerHello.random);
server_write_IV = MD5(ServerHello.random + ClientHello.random);
MD5 outputs are trimmed to the appropriate size by discarding the least-significant bytes.
通过丢弃最低有效字节，MD5输出被修剪到适当的大小。
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for each of the two encryption keys and 16 bytes for each of the MAC keys, for a total of 42 bytes of key material. MD5 produces 16 bytes of output per call, so three calls to MD5 are required. The MD5 outputs are concatenated into a 48-byte key_block with the first MD5 call providing bytes zero through 15, the second providing bytes 16 through 31, etc. The key_block is partitioned, and the write keys are salted because this is an exportable encryption algorithm.
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5需要两个加密密钥各5个随机字节，MAC密钥各16个字节，总共需要42个字节的密钥材料。MD5每次调用产生16字节的输出，因此需要对MD5进行三次调用。MD5输出被连接到一个48字节的key_块中，第一个MD5调用提供字节0到15，第二个MD5调用提供字节16到31，等等。key_块被分区，写入密钥被盐析，因为这是一个可导出的加密算法。
client_write_MAC_secret = key_block[0..15]
server_write_MAC_secret = key_block[16..31]
client_write_key = key_block[32..36]
server_write_key = key_block[37..41]
final_client_write_key = MD5(client_write_key +
ClientHello.random +
ServerHello.random)[0..15];
final_server_write_key = MD5(server_write_key +
ServerHello.random +
ClientHello.random)[0..15];
client_write_IV = MD5(ClientHello.random +
ServerHello.random)[0..7];
server_write_IV = MD5(ServerHello.random +
ClientHello.random)[0..7];
client_write_MAC_secret = key_block[0..15]
server_write_MAC_secret = key_block[16..31]
client_write_key = key_block[32..36]
server_write_key = key_block[37..41]
final_client_write_key = MD5(client_write_key +
ClientHello.random +
ServerHello.random)[0..15];
final_server_write_key = MD5(server_write_key +
ServerHello.random +
ClientHello.random)[0..15];
client_write_IV = MD5(ClientHello.random +
ServerHello.random)[0..7];
server_write_IV = MD5(ServerHello.random +
ClientHello.random)[0..7];
See Appendix F.
见附录F。
[DH1] Diffie, W. and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory V. IT-22, n. 6, pp. 74-84, June 1977.
[DH1]Diffie，W.和M.Hellman，“密码学的新方向”，IEEE信息论交易V.IT-22，n。1977年6月6日，第74-84页。
[SSL-2] Hickman, K., "The SSL Protocol", February 1995.
[SSL-2]Hickman，K.，“SSL协议”，1995年2月。
[3DES] Tuchman, W., "Hellman Presents No Shortcut Solutions To DES", IEEE Spectrum, v. 16, n. 7, pp 40-41, July 1979.
[3DES]Tuchman，W.，“Hellman对DES没有捷径解决方案”，IEEE Spectrum，v。16，n。1979年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, "Digital Signature Standard", National Institute of Standards and Technology U.S. Department of Commerce, May 1994.
[DSS]NIST FIPS PUB 186，“数字签名标准”，美国商务部国家标准与技术研究所，1994年5月。
[FOR] NSA X22, "FORTEZZA: Application Implementers Guide", Document # PD4002103-1.01, April 1995.
[适用于]NSA X22，“FORTEZZA：应用程序实施者指南”，文件#PD4002103-1.011995年4月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945]Berners Lee，T.，Fielding，R.，和H.Nielsen，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[RFC0854]Postel，J.和J.Reynolds，“Telnet协议规范”，STD 8，RFC 854，1983年5月。
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[RFC1832]Srinivasan，R.，“XDR：外部数据表示标准”，RFC 1832，1995年8月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[IDEA] Lai, X., "On the Design and Security of Block Ciphers", ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.
[IDEA]Lai，X.，“分组密码的设计与安全”，信息处理ETH系列，v。康斯坦茨：哈东·高尔·韦拉格，1992年。
[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard version 1.5", November 1993.
[PKCS1]RSA实验室，“PKCS#1:RSA加密标准1.5版”，1993年11月。
[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月。
[RSA] Rivest, R., Shamir, A., and L. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM v. 21, n. 2 pp. 120-126., February 1978.
[RSA]Rivest，R.，Shamir，A.，和L.Adleman，“获取数字签名和公钥密码系统的方法”，ACM v.的通信。21，n。第120-126页，1978年2月。
[SCH] Schneier, B., "Applied Cryptography: Protocols, Algorithms, and Source Code in C", John Wiley & Sons, 1994.
[SCH]Schneier，B.，“应用密码学：C语言中的协议、算法和源代码”，John Wiley&Sons，1994年。
[SHA] NIST FIPS PUB 180-1, "Secure Hash Standard", May 1994.
[SHA]NIST FIPS PUB 180-1，“安全哈希标准”，1994年5月。
National Institute of Standards and Technology, U.S. Department of Commerce, DRAFT
美国商务部国家标准与技术研究所，草案
[X509] CCITT, "The Directory - Authentication Framework", Recommendation X.509 , 1988.
[X509]CCITT，“目录认证框架”，建议X.5092988。
[RSADSI] RSA Data Security, Inc., "Unpublished works".
[RSADSI]RSA数据安全公司，“未出版作品”。
This section describes protocol types and constants.
本节介绍协议类型和常量。
struct {
uint8 major, minor;
} ProtocolVersion;
struct {
uint8 major, minor;
} ProtocolVersion;
ProtocolVersion version = { 3,0 };
ProtocolVersion version = { 3,0 };
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[SSLPlaintext.length];
} SSLPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[SSLPlaintext.length];
} SSLPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[SSLCompressed.length];
} SSLCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[SSLCompressed.length];
} SSLCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} SSLCiphertext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} SSLCiphertext;
stream-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
stream-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
block-ciphered struct {
opaque content[SSLCompressed.length];
block-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
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),
decompression_failure(30),
handshake_failure(40),
no_certificate(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter (47),
(255)
} AlertDescription;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decompression_failure(30),
handshake_failure(40),
no_certificate(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter (47),
(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_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_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_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_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<0..2^16-1>;
CompressionMethod compression_methods<0..2^8-1>;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<0..2^16-1>;
CompressionMethod compression_methods<0..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<1..2^24-1>;
} Certificate;
struct {
ASN.1Cert certificate_list<1..2^24-1>;
} Certificate;
enum { rsa, diffie_hellman, fortezza_kea } KeyExchangeAlgorithm;
enum { rsa, diffie_hellman, fortezza_kea } 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 {
opaque r_s [128]
} ServerFortezzaParams
struct {
opaque r_s [128]
} ServerFortezzaParams
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
case fortezza_kea:
ServerFortezzaParams params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
case fortezza_kea:
ServerFortezzaParams params;
};
} ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
digitally-signed struct {
select(SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
opaque md5_hash[16];
opaque sha_hash[20];
case dsa:
opaque sha_hash[20];
};
} Signature;
digitally-signed struct {
select(SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
opaque md5_hash[16];
opaque sha_hash[20];
case dsa:
opaque sha_hash[20];
};
} Signature;
enum {
RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3),
DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6),
FORTEZZA_MISSI(20), (255)
} CertificateType;
enum {
RSA_sign(1), DSS_sign(2), RSA_fixed_DH(3),
DSS_fixed_DH(4), RSA_ephemeral_DH(5), DSS_ephemeral_DH(6),
FORTEZZA_MISSI(20), (255)
} CertificateType;
opaque DistinguishedName<1..2^16-1>;
opaque DistinguishedName<1..2^16-1>;
struct {
CertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;
struct {
CertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;
struct { } ServerHelloDone;
struct { } ServerHelloDone;
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: DiffieHellmanClientPublicValue;
case fortezza_kea: FortezzaKeys;
} exchange_keys;
} ClientKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: DiffieHellmanClientPublicValue;
case fortezza_kea: FortezzaKeys;
} 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;
struct {
opaque y_c<0..128>;
opaque r_c[128];
opaque y_signature[40];
opaque wrapped_client_write_key[12];
opaque wrapped_server_write_key[12];
opaque client_write_iv[24];
opaque server_write_iv[24];
opaque master_secret_iv[24];
opaque encrypted_preMasterSecret[48];
} FortezzaKeys;
struct {
opaque y_c<0..128>;
opaque r_c[128];
opaque y_signature[40];
opaque wrapped_client_write_key[12];
opaque wrapped_server_write_key[12];
opaque client_write_iv[24];
opaque server_write_iv[24];
opaque master_secret_iv[24];
opaque encrypted_preMasterSecret[48];
} FortezzaKeys;
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 md5_hash[16];
opaque sha_hash[20];
} Finished;
struct {
opaque md5_hash[16];
opaque sha_hash[20];
} Finished;
The following values define the CipherSuite codes used in the client hello and server hello messages.
以下值定义了客户端hello和服务器hello消息中使用的密码套件代码。
A CipherSuite defines a cipher specifications supported in SSL version 3.0.
密码套件定义SSL版本3.0中支持的密码规范。
CipherSuite SSL_NULL_WITH_NULL_NULL = { 0x00,0x00 };
CipherSuite SSL_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 SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
CipherSuite SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
CipherSuite SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite SSL_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, which has been signed by the CA. The signing algorithm used is specified after the DH or DHE parameter. In all cases, the client must have the same type of certificate, and must use the Diffie-Hellman parameters chosen by the server.
以下密码套件定义用于服务器身份验证（以及可选的客户端身份验证）Diffie Hellman。DH表示密码套件，其中服务器的证书包含由证书颁发机构（CA）签名的Diffie-Hellman参数。DHE表示短暂的Diffie-Hellman，其中Diffie-Hellman参数由已由CA签名的DSS或RSA证书签名。使用的签名算法在DH或DHE参数后指定。在所有情况下，客户端必须具有相同类型的证书，并且必须使用服务器选择的Diffie-Hellman参数。
CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite SSL_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 strongly discouraged.
以下密码套件用于完全匿名的Diffie-Hellman通信，其中任何一方都没有经过身份验证。请注意，此模式容易受到中间人攻击，因此强烈建议不要使用。
CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
The final cipher suites are for the FORTEZZA token.
最后的密码套件用于FORTEZZA令牌。
CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = { 0X00,0X1C };
CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D };
CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = { 0x00,0x1E };
CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = { 0X00,0X1C };
CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D };
CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = { 0x00,0x1E };
Note: All cipher suites whose first byte is 0xFF are considered private and can be used for defining local/experimental algorithms. Interoperability of such types is a local matter.
注意：第一个字节为0xFF的所有密码套件都被视为专用密码套件，可用于定义本地/实验算法。此类类型的互操作性是一个局部问题。
A cipher suite identifies a CipherSpec. These structures are part of the SSL session state. The CipherSpec includes:
密码套件标识密码规范。这些结构是SSL会话状态的一部分。CipherSpec包括：
enum { stream, block } CipherType;
enum { stream, block } CipherType;
enum { true, false } IsExportable;
enum { true, false } IsExportable;
enum { null, rc4, rc2, des, 3des, des40, fortezza }
BulkCipherAlgorithm;
enum { null, rc4, rc2, des, 3des, des40, fortezza }
BulkCipherAlgorithm;
enum { null, md5, sha } MACAlgorithm;
enum { null, md5, sha } MACAlgorithm;
struct {
BulkCipherAlgorithm bulk_cipher_algorithm;
MACAlgorithm mac_algorithm;
CipherType cipher_type;
IsExportable is_exportable
uint8 hash_size;
uint8 key_material;
uint8 IV_size;
} CipherSpec;
struct {
BulkCipherAlgorithm bulk_cipher_algorithm;
MACAlgorithm mac_algorithm;
CipherType cipher_type;
IsExportable is_exportable
uint8 hash_size;
uint8 key_material;
uint8 IV_size;
} CipherSpec;
application protocol: An application protocol is a protocol that normally layers directly on top of the transport layer (e.g., TCP/IP [RFC0793]/[RFC0791]). Examples include HTTP [RFC1945], TELNET [RFC0959], FTP [RFC0854], and SMTP.
应用协议：应用协议是一种通常直接在传输层之上分层的协议（例如TCP/IP[RFC0793]/[RFC0791]）。示例包括HTTP[RFC1945]、TELNET[RFC0959]、FTP[RFC0854]和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 typical block size.
分组密码：分组密码是一种以位为单位对明文进行运算的算法，称为块。64位是典型的块大小。
bulk cipher: A symmetric encryption algorithm used to encrypt large quantities of data.
批量加密：一种对称加密算法，用于加密大量数据。
cipher block chaining (CBC) mode: CBC is a mode in which every plaintext block encrypted with the block cipher is first exclusive-ORed with the previous ciphertext block (or, in the case of the first block, with the initialization vector).
密码块链接（CBC）模式：CBC是一种模式，其中使用分组密码加密的每个明文块首先与前一个密文块（或者，在第一个块的情况下，与初始化向量）进行异或。
certificate: As part of the X.509 protocol (a.k.a. ISO Authentication framework), certificates are assigned by a trusted certificate authority and provide verification of a party's identity and may also supply its public key.
证书：作为X.509协议（又称ISO认证框架）的一部分，证书由受信任的证书颁发机构分配，用于验证一方的身份，还可以提供其公钥。
client: The application entity that initiates a connection to a server.
客户端：启动与服务器连接的应用程序实体。
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 SSL, such connections are peer-to-peer relationships. The connections are transient. Every connection is associated with one session.
连接：连接是提供适当类型服务的传输（在OSI分层模型定义中）。对于SSL，这种连接是对等关系。连接是暂时的。每个连接都与一个会话相关联。
Data Encryption Standard (DES): DES is a very widely used symmetric encryption algorithm. DES is a block cipher [DES] [3DES].
数据加密标准（DES）：DES是一种应用非常广泛的对称加密算法。DES是一种分组密码[DES][3DES]。
Digital Signature Standard: (DSS) A standard for digital signing, including the Digital Signature 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）美国国家标准与技术研究所批准的数字签名标准，包括数字签名算法，由美国商务部于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.
数字签名：数字签名利用公钥密码和单向散列函数生成数据签名，该数据签名可通过身份验证，且难以伪造或否认。
FORTEZZA: A PCMCIA card that provides both encryption and digital signing.
FORTEZZA：提供加密和数字签名的PCMCIA卡。
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].
IDEA：由赖学佳和James Massey设计的64位分组密码[IDEA]。
Message Authentication Code (MAC): A Message Authentication Code is a one-way hash computed from a message and some 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 [RFC1321] is a secure hashing function that converts an arbitrarily long data stream into a digest of fixed size.
MD5:MD5[RFC1321]是一个安全的哈希函数，它将任意长的数据流转换为固定大小的摘要。
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, RC4: Proprietary bulk ciphers from RSA Data Security, Inc. (There is no good reference to these as they are unpublished works; however, see [RSADSI]). RC2 is a block cipher and RC4 is a stream cipher.
RC2，RC4：RSA Data Security，Inc.的专有批量密码（由于这些密码是未出版的作品，因此没有很好的参考资料；但是，请参见[RSADSI]）。RC2是分组密码，RC4是流密码。
RSA: A very widely used public key algorithm that can be used for either encryption or digital signing.
RSA：一种广泛使用的公钥算法，可用于加密或数字签名。
salt: Non-secret random data used to make export encryption keys resist precomputation attacks.
salt：用于使导出加密密钥抵抗预计算攻击的非秘密随机数据。
server: The server is the application entity that responds to requests for connections from clients. The server is passive, waiting for requests from clients.
服务器：服务器是响应客户端连接请求的应用程序实体。服务器是被动的，等待客户端的请求。
session: An SSL 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, which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.
会话：SSL会话是客户端和服务器之间的关联。会话是通过握手协议创建的。会话定义一组加密安全参数，可在多个连接之间共享。会话用于避免为每个连接协商昂贵的新安全参数。
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-1. It produces a 20-byte output [SHA].
SHA：安全哈希算法在FIPS PUB 180-1中定义。它产生一个20字节的输出[SHA]。
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.
对称密码：参见批量密码。
CipherSuite Is Key Cipher Hash Exportable Exchange
CipherSuite是密钥密码哈希可导出交换
SSL_NULL_WITH_NULL_NULL * NULL NULL NULL SSL_RSA_WITH_NULL_MD5 * RSA NULL MD5 SSL_RSA_WITH_NULL_SHA * RSA NULL SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 * RSA_EXPORT RC4_40 MD5 SSL_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 SSL_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 * RSA_EXPORT RC2_CBC_40 MD5 SSL_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA SSL_RSA_EXPORT_WITH_DES40_CBC_SHA * RSA_EXPORT DES40_CBC SHA SSL_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA * DH_DSS_EXPORT DES40_CBC SHA SSL_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA * DH_RSA_EXPORT DES40_CBC SHA SSL_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA * DHE_DSS_EXPORT DES40_CBC SHA SSL_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA * DHE_RSA_EXPORT DES40_CBC SHA SSL_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 * DH_anon_EXPORT RC4_40 MD5 SSL_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA DH_anon DES40_CBC SHA SSL_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA SSL_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA SSL_FORTEZZA_KEA_WITH_NULL_SHA FORTEZZA_KEA NULL SHA SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA FORTEZZA_KEA FORTEZZA_CBC SHA SSL_FORTEZZA_KEA_WITH_RC4_128_SHA FORTEZZA_KEA RC4_128 SHA
（U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U U库沙RSA（CBC）沙沙沙沙沙（CBC）沙沙沙（沙）沙（沙）沙（沙）概念概念概念，CBC沙沙沙沙（沙）概念概念，CBC沙沙沙（沙）沙沙（沙）沙（沙）沙（沙）沙（沙）沙（沙）概念概念，RSA（沙）概念概念概念概念概念概念概念概念概念，出口（出口）沙沙沙沙（沙）沙沙沙沙（沙）沙沙（沙）沙（沙）沙（沙）沙（沙）沙（沙）沙）沙（沙）沙（沙）沙（沙）沙（沙）沙）沙（沙）沙）沙（沙）沙（沙）沙（沙（沙）沙）沙（沙）沙（沙）沙）沙（沙）沙）沙）沙（沙）沙（沙（沙）沙）沙）沙）沙）沙（沙（沙（沙）沙）沙）沙）沙）沙（沙（沙（沙（沙）沙）概念概念概念概念概念概念，CBC_SHA DH_DSS 3DES_EDE_CBC SHA加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密出口出口出口加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密出口出口出口出口出口加密加密加密加密加密加密加密加密加密加密加密出口出口出口出口加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密出口出口出口加密加密加密加密加密加密加密加密加密出口加密出口加密出口加密出口加密出口加密出口加密出口加密加密加密加密加密出口加密加密加密加密加密加密出口加密加密加密加密加密加密加密加密出口加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密出口加密加密加密加密加密加密加密加密加密加密加密加密加密加密E_DSS_与_3DES_EDE_CBC_SHA_DSS_3DES_EDE_CBC SHA加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密出口加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密出口出口加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密出口出口出口出口出口加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密加密SSL_DH_anon_EXPORT_与_DES40_CBC_SHA_anon DES40_CBC SHA与CBC一起使用的SSL与CBC一起使用，与CBC一起使用，与CBC一起使用，与CBC一起使用，与CBC一起使用，与CBC一起使用，与CBC一起使用，与CBC一起使用，与CBC一起使用，与CBC一起使用，与CBC一起使用
+----------------+------------------------------+-------------------+
| Key Exchange | Description | Key Size Limit |
| Algorithm | | |
+----------------+------------------------------+-------------------+
| DHE_DSS | Ephemeral DH with DSS | None |
| | signatures | |
| DHE_DSS_EXPORT | Ephemeral DH with DSS | DH = 512 bits |
| | signatures | |
| DHE_RSA | Ephemeral DH with RSA | None |
| | signatures | |
| DHE_RSA_EXPORT | Ephemeral DH with RSA | DH = 512 bits, |
| | signatures | RSA = none |
| DH_anon | Anonymous DH, no signatures | None |
| DH_anon_EXPORT | Anonymous DH, no signatures | DH = 512 bits |
| DH_DSS | DH with DSS-based | None |
| | certificates | |
| DH_DSS_EXPORT | DH with DSS-based | DH = 512 bits |
| | certificates | |
| DH_RSA | DH with RSA-based | None |
| | certificates | |
| DH_RSA_EXPORT | DH with RSA-based | DH = 512 bits, |
| | certificates | RSA = none |
| FORTEZZA_KEA | FORTEZZA KEA. Details | N/A |
| | unpublished | |
| NULL | No key exchange | N/A |
| RSA | RSA key exchange | None |
| RSA_EXPORT | RSA key exchange | RSA = 512 bits |
+----------------+------------------------------+-------------------+
+----------------+------------------------------+-------------------+
| Key Exchange | Description | Key Size Limit |
| Algorithm | | |
+----------------+------------------------------+-------------------+
| DHE_DSS | Ephemeral DH with DSS | None |
| | signatures | |
| DHE_DSS_EXPORT | Ephemeral DH with DSS | DH = 512 bits |
| | signatures | |
| DHE_RSA | Ephemeral DH with RSA | None |
| | signatures | |
| DHE_RSA_EXPORT | Ephemeral DH with RSA | DH = 512 bits, |
| | signatures | RSA = none |
| DH_anon | Anonymous DH, no signatures | None |
| DH_anon_EXPORT | Anonymous DH, no signatures | DH = 512 bits |
| DH_DSS | DH with DSS-based | None |
| | certificates | |
| DH_DSS_EXPORT | DH with DSS-based | DH = 512 bits |
| | certificates | |
| DH_RSA | DH with RSA-based | None |
| | certificates | |
| DH_RSA_EXPORT | DH with RSA-based | DH = 512 bits, |
| | certificates | RSA = none |
| FORTEZZA_KEA | FORTEZZA KEA. Details | N/A |
| | unpublished | |
| NULL | No key exchange | N/A |
| RSA | RSA key exchange | None |
| RSA_EXPORT | RSA key exchange | RSA = 512 bits |
+----------------+------------------------------+-------------------+
Table 1
表1
Key size limit: The key size limit gives the size of the largest public key that can be legally used for encryption in cipher suites that are exportable.
密钥大小限制：密钥大小限制提供可合法用于可导出密码套件中加密的最大公钥的大小。
+--------------+--------+-----+-------+-------+-------+------+------+
| Cipher | Cipher | IsE | Key | Exp. | Effec | IV | Bloc |
| | Type | xpo | Mater | Key | tive | Size | k |
| | | rta | ial | Mater | Key | | Size |
| | | ble | | ial | Bits | | |
+--------------+--------+-----+-------+-------+-------+------+------+
| NULL | Stream | * | 0 | 0 | 0 | 0 | N/A |
| FORTEZZA_CBC | Block | | NA | 12 | 96 | 20 | 8 |
| | | | (**) | (**) | (**) | (**) | |
| IDEA_CBC | Block | | 16 | 16 | 128 | 8 | 8 |
| RC2_CBC_40 | Block | * | 5 | 16 | 40 | 8 | 8 |
| RC4_40 | Stream | * | 5 | 16 | 40 | 0 | N/A |
| RC4_128 | Stream | | 16 | 16 | 128 | 0 | N/A |
| DES40_CBC | Block | * | 5 | 8 | 40 | 8 | 8 |
| DES_CBC | Block | | 8 | 8 | 56 | 8 | 8 |
| 3DES_EDE_CBC | Block | | 24 | 24 | 168 | 8 | 8 |
+--------------+--------+-----+-------+-------+-------+------+------+
+--------------+--------+-----+-------+-------+-------+------+------+
| Cipher | Cipher | IsE | Key | Exp. | Effec | IV | Bloc |
| | Type | xpo | Mater | Key | tive | Size | k |
| | | rta | ial | Mater | Key | | Size |
| | | ble | | ial | Bits | | |
+--------------+--------+-----+-------+-------+-------+------+------+
| NULL | Stream | * | 0 | 0 | 0 | 0 | N/A |
| FORTEZZA_CBC | Block | | NA | 12 | 96 | 20 | 8 |
| | | | (**) | (**) | (**) | (**) | |
| IDEA_CBC | Block | | 16 | 16 | 128 | 8 | 8 |
| RC2_CBC_40 | Block | * | 5 | 16 | 40 | 8 | 8 |
| RC4_40 | Stream | * | 5 | 16 | 40 | 0 | N/A |
| RC4_128 | Stream | | 16 | 16 | 128 | 0 | N/A |
| DES40_CBC | Block | * | 5 | 8 | 40 | 8 | 8 |
| DES_CBC | Block | | 8 | 8 | 56 | 8 | 8 |
| 3DES_EDE_CBC | Block | | 24 | 24 | 168 | 8 | 8 |
+--------------+--------+-----+-------+-------+-------+------+------+
* Indicates IsExportable is true. ** FORTEZZA uses its own key and IV generation algorithms.
*表示IsExportable为true。**FORTEZZA使用自己的密钥和IV生成算法。
Table 2
表2
Key Material: The number of bytes from the key_block that are used for generating the write keys.
Key Material：Key_块中用于生成写密钥的字节数。
Expanded Key Material: The number of bytes actually fed into the encryption algorithm.
扩展密钥材料：实际输入加密算法的字节数。
Effective Key Bits: How much entropy material is in the key material being fed into the encryption routines.
有效密钥位：输入加密例程的密钥材料中有多少熵材料。
+---------------+-----------+--------------+
| Hash Function | Hash Size | Padding Size |
+---------------+-----------+--------------+
| NULL | 0 | 0 |
| MD5 | 16 | 48 |
| SHA | 20 | 40 |
+---------------+-----------+--------------+
+---------------+-----------+--------------+
| Hash Function | Hash Size | Padding Size |
+---------------+-----------+--------------+
| NULL | 0 | 0 |
| MD5 | 16 | 48 |
| SHA | 20 | 40 |
+---------------+-----------+--------------+
Table 3
表3
The SSL protocol cannot prevent many common security mistakes. This section provides several recommendations to assist implementers.
SSL协议无法防止许多常见的安全错误。本节提供了一些帮助实施者的建议。
US export restrictions limit RSA keys used for encryption to 512 bits, but do not place any limit on lengths of RSA keys used for signing operations. Certificates often need to be larger than 512 bits, since 512-bit RSA keys are not secure enough for high-value transactions or for applications requiring long-term security. Some certificates are also designated signing-only, in which case they cannot be used for key exchange.
美国出口限制将用于加密的RSA密钥限制为512位，但不限制用于签名操作的RSA密钥的长度。证书通常需要大于512位，因为512位RSA密钥对于高价值事务或需要长期安全性的应用程序来说不够安全。有些证书也被指定为仅签名，在这种情况下，它们不能用于密钥交换。
When the public key in the certificate cannot be used for encryption, the server signs a temporary RSA key, which is then exchanged. In exportable applications, the temporary RSA key should be the maximum allowable length (i.e., 512 bits). Because 512-bit RSA keys are relatively insecure, they should be changed often. For typical electronic commerce applications, it is suggested that keys be changed daily or every 500 transactions, and more often if possible. Note that while it is acceptable to use the same temporary key for multiple transactions, it must be signed each time it is used.
当证书中的公钥不能用于加密时，服务器会签署一个临时RSA密钥，然后交换该密钥。在可导出应用程序中，临时RSA密钥应为允许的最大长度（即512位）。因为512位RSA密钥相对不安全，所以应该经常更改它们。对于典型的电子商务应用程序，建议每天或每500笔交易更换一次密钥，如果可能，更频繁地更换密钥。请注意，虽然可以对多个事务使用同一临时密钥，但每次使用时都必须对其进行签名。
RSA key generation is a time-consuming process. In many cases, a low-priority process can be assigned the task of key generation. Whenever a new key is completed, the existing temporary key can be replaced with the new one.
RSA密钥生成是一个耗时的过程。在许多情况下，可以为低优先级进程分配密钥生成任务。每当新密钥完成时，可以用新密钥替换现有的临时密钥。
SSL 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.)
SSL需要加密安全的伪随机数生成器（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. To seed a 128-bit PRNG, one would thus require approximately 100 such timer values.
要估计正在生成的种子材料的数量，请在每个种子字节中添加不可预测信息的位数。例如，即使计数器值的总大小为16位或更多，从PC兼容的18.2 Hz定时器获取的击键定时值也会提供1或2个安全位。因此，要为128位PRNG设定种子，需要大约100个这样的计时器值。
Note: The seeding functions in RSAREF and versions of BSAFE prior to 3.0 are order independent. For example, if 1000 seed bits are supplied, one at a time, in 1000 separate calls to the seed function, the PRNG will end up in a state that depends only on the number of 0 or 1 seed bits in the seed data (i.e., there are 1001 possible final states). Applications using BSAFE or RSAREF must take extra care to ensure proper seeding.
注：RSAREF和BSAFE 3.0之前版本中的种子设定功能与订单无关。例如，如果在对seed函数的1000次单独调用中一次提供1000个种子位，则PRNG将处于仅取决于种子数据中0或1个种子位的数量的状态（即，存在1001个可能的最终状态）。使用BSAFE或RSAREF的应用程序必须格外小心，以确保正确播种。
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的信息。
SSL 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.
SSL支持一系列密钥大小和安全级别，包括一些不提供安全性或最低安全性的密钥。正确的实现可能不支持许多密码套件。例如，40位加密很容易被破坏，因此需要强安全性的实现不应该允许使用40位密钥。类似地，匿名Diffie Hellman也被强烈劝阻，因为它无法阻止中间人攻击。应用程序还应强制执行最小和最大密钥大小。例如，包含512位RSA密钥或签名的证书链不适用于高安全性应用程序。
This section describes implementation details for cipher suites that make use of the FORTEZZA hardware encryption system.
本节介绍使用FORTEZZA硬件加密系统的密码套件的实现细节。
A complete explanation of all issues regarding the use of FORTEZZA hardware is outside the scope of this document. However, there are a few special requirements of SSL that deserve mention.
有关FORTEZZA硬件使用的所有问题的完整解释不在本文档范围内。然而，SSL有一些特殊要求值得一提。
Because SSL is a full duplex protocol, two crypto states must be maintained, one for reading and one for writing. There are also a number of circumstances that can result in the crypto state in the FORTEZZA card being lost. For these reasons, it's recommended that the current crypto state be saved after processing a record, and loaded before processing the next.
因为SSL是全双工协议，所以必须维护两种加密状态，一种用于读取，另一种用于写入。还有许多情况会导致FORTEZZA卡中的加密状态丢失。出于这些原因，建议在处理记录之后保存当前加密状态，并在处理下一条记录之前加载。
After the client generates the TEK, it also generates two message encryption keys (MEKs), one for reading and one for writing. After generating each of these keys, the client must generate a corresponding IV and then save the crypto state. The client also uses the TEK to generate an IV and encrypt the premaster secret. All three IVs are sent to the server, along with the wrapped keys and the encrypted premaster secret in the client key exchange message. At this point, the TEK is no longer needed, and may be discarded.
在客户端生成TEK之后，它还生成两个消息加密密钥（MEK），一个用于读取，一个用于写入。生成每个密钥后，客户端必须生成相应的IV，然后保存加密状态。客户端还使用TEK生成IV并加密premaster机密。所有三个IV都将与客户机密钥交换消息中的打包密钥和加密的premaster机密一起发送到服务器。此时，TEK不再需要，可能会被丢弃。
On the server side, the server uses the master IV and the TEK to decrypt the premaster secret. It also loads the wrapped MEKs into the card. The server loads both IVs to verify that the IVs match the keys. However, since the card is unable to encrypt after loading an IV, the server must generate a new IV for the server write key. This IV is discarded.
在服务器端，服务器使用master IV和TEK解密premaster机密。它还将包装好的MEK装入卡中。服务器加载两个IV以验证IV是否与密钥匹配。但是，由于卡在加载IV后无法加密，服务器必须为服务器写入密钥生成新的IV。这个IV被丢弃了。
When encrypting the first encrypted record (and only that record), the server adds 8 bytes of random data to the beginning of the fragment. These 8 bytes are discarded by the client after decryption. The purpose of this is to synchronize the state on the client and server resulting from the different IVs.
当加密第一条加密记录（并且仅加密该记录）时，服务器会在片段的开头添加8字节的随机数据。解密后，客户端将丢弃这8个字节。这样做的目的是同步客户端和服务器上由不同IVs产生的状态。
5) FORTEZZA_NULL_WITH_NULL_SHA: Uses the full FORTEZZA key exchange, including sending server and client write keys and IVs.
5) FORTEZZA_NULL_WITH_NULL_SHA：使用完整的FORTEZZA密钥交换，包括发送服务器和客户端写入密钥和IVs。
There are two possibilities for FORTEZZA session restart: 1) Never restart a FORTEZZA session. 2) Restart a session with the previously negotiated keys and IVs.
FORTEZZA会话重启有两种可能性：1）永远不要重启FORTEZZA会话。2） 使用先前协商的密钥和IVs重新启动会话。
Never restarting a FORTEZZA session:
从不重新启动FORTEZZA会话：
Clients who never restart FORTEZZA sessions should never send session IDs that were previously used in a FORTEZZA session as part of the ClientHello. Servers who never restart FORTEZZA sessions should never send a previous session id on the ServerHello if the negotiated session is FORTEZZA.
从不重新启动FORTEZZA会话的客户端不应发送以前在FORTEZZA会话中作为ClientHello的一部分使用的会话ID。如果协商的会话是FORTEZZA，则从不重新启动FORTEZZA会话的服务器不应在ServerHello上发送以前的会话id。
Restart a session:
重新启动会话：
You cannot restart FORTEZZA on a session that has never done a complete FORTEZZA key exchange (that is, you cannot restart FORTEZZA if the session was an RSA/RC4 session renegotiated for FORTEZZA). If you wish to restart a FORTEZZA session, you must save the MEKs and
无法在从未完成完整FORTEZZA密钥交换的会话上重新启动FORTEZZA（即，如果会话是为FORTEZZA重新协商的RSA/RC4会话，则无法重新启动FORTEZZA）。如果要重新启动FORTEZZA会话，必须保存MEK和
IVs from the initial key exchange for this session and reuse them for any new connections on that session. This is not recommended, but it is possible.
来自此会话的初始密钥交换的IVs，并将其重新用于该会话上的任何新连接。不建议这样做，但这是可能的。
Version 3.0 clients that support version 2.0 servers must send version 2.0 client hello messages [SSL-2]. Version 3.0 servers should accept either client hello format. 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.
支持2.0版服务器的3.0版客户端必须发送2.0版客户端hello消息[SSL-2]。3.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. Implementers should make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for transitioning 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 SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
= { 0x04,0x00,0x80 };
V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
V2CipherSpec SSL_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 };
V2CipherSpec SSL_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec SSL_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec SSL_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
= { 0x04,0x00,0x80 };
V2CipherSpec SSL_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec SSL_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec SSL_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
Cipher specifications introduced in version 3.0 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 version 3.0 equivalent (see Appendix A.6):
版本3.0中引入的密码规范可以使用以下语法包含在版本2.0客户机hello消息中。版本2.0服务器将忽略第一个字节等于零的V2CipherSpec元素。发送上述V2CipherSpec的客户端还应包括3.0版的等效版本（见附录A.6）：
V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite };
V2CipherSpec (see Version 3.0 name) = { 0x00, CipherSuite };
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.
下面使用本文档的表示模型显示了2.0版客户端hello消息。真正的定义仍然假定为SSL版本2.0规范。
uint8 V2CipherSpec[3];
uint8 V2CipherSpec[3]；
struct {
unit8 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];
Random challenge;
} V2ClientHello;
struct {
unit8 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];
Random challenge;
} V2ClientHello;
session msg_type: This field, in conjunction with the version field, identifies a version 2 client hello message. The value should equal one (1).
会话消息类型：此字段与版本字段一起标识版本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 either zero or 16. If zero, the client is creating a new session. If 16, the session_id field will contain the 16 bytes of session identification.
会话id长度：此字段的值必须为零或16。如果为零，则客户端正在创建新会话。如果为16，会话id字段将包含16字节的会话标识。
challenge_length: The length in bytes of the client's challenge to the server to authenticate itself. This value must be 32.
challenge_length：客户端向服务器发出的验证自身身份的质询的长度（以字节为单位）。此值必须为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: If this field's length is not zero, it will contain the identification for a session that the client wishes to resume.
会话id：如果此字段的长度不为零，则它将包含客户端希望恢复的会话的标识。
challenge: The client's challenge to the server for the server to identify itself is a (nearly) arbitrary length random. The version 3.0 server will right justify the challenge data to become the ClientHello.random data (padded with leading zeroes, if necessary), as specified in this version 3.0 protocol. If the length of the challenge is greater than 32 bytes, then 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.
质询：客户端对服务器的质询是（几乎）任意长度的随机质询。版本3.0服务器将正确证明质询数据成为ClientHello.random数据（如有必要，用前导零填充），如版本3.0协议中所述。如果质询的长度大于32字节，则仅使用最后32字节。V3服务器拒绝具有少于16字节质询数据的V2 ClientHello是合法的（但不是必需的）。
Note: Requests to resume an SSL 3.0 session should use an SSL 3.0 client hello.
注意：恢复SSL 3.0会话的请求应使用SSL 3.0客户端。
When SSL version 3.0 clients fall back to version 2.0 compatibility mode, they use special PKCS #1 block formatting. This is done so that version 3.0 servers will reject version 2.0 sessions with version 3.0-capable clients.
当SSL 3.0版客户端退回到2.0版兼容模式时，它们使用特殊的PKCS#1块格式。这样做的目的是，3.0版服务器将拒绝具有3.0版客户端的2.0版会话。
When version 3.0 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 SSL 3.0 should issue an error if these eight padding bytes are 0x03. Version 2.0 servers receiving blocks padded in this manner will proceed normally.
当版本3.0客户端处于版本2.0兼容模式时，它们将PKCS填充的右侧（最低有效）8个随机字节（不包括填充的终端null）设置为0x03（其他填充字节是随机的），用于客户端主密钥的加密-KEY-DATA字段的RSA加密。解密加密的-KEY-DATA字段后，如果这八个填充字节为0x03，则支持SSL 3.0的服务器应发出错误。接收以这种方式填充的块的2.0版服务器将正常运行。
The SSL 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 SSL has been designed to resist a variety of attacks.
SSL协议旨在通过不安全的通道在客户端和服务器之间建立安全连接。本文档做出了一些传统假设，包括攻击者拥有大量计算资源，无法从协议之外的来源获取机密信息。假定攻击者能够捕获、修改、删除、重播或以其他方式篡改通过通信通道发送的消息。本附录概述了如何设计SSL来抵御各种攻击。
The handshake protocol is responsible for selecting a CipherSpec and generating a MasterSecret, 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.
握手协议负责选择密码规范并生成主密钥，其共同包括与安全会话相关联的主要密码参数。握手协议还可以选择性地对拥有由可信证书颁发机构签署的证书的各方进行身份验证。
SSL supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel should be secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks.
SSL支持三种身份验证模式：双方的身份验证、未经身份验证的客户端的服务器身份验证和完全匿名。无论何时对服务器进行身份验证，通道都应该能够抵御中间人攻击，但完全匿名会话本身就容易受到此类攻击。
Anonymous servers cannot authenticate clients, since the client signature in the certificate verify message may require a server certificate to bind the signature to a particular server. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked.
匿名服务器无法对客户端进行身份验证，因为证书验证消息中的客户端签名可能需要服务器证书才能将签名绑定到特定服务器。如果服务器经过身份验证，则其证书消息必须提供一个有效的证书链，指向可接受的证书颁发机构。类似地，经过身份验证的客户端必须向服务器提供可接受的证书。各方负责验证另一方的证书是否有效且未过期或被撤销。
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 6.1). The master_secret is required to generate the finished messages, encryption keys, and MAC secrets (see Sections 5.6.9 and 6.2.2). By sending a correct finished message, parties thus prove that they know the correct pre_master_secret.
密钥交换过程的总体目标是创建通信方而非攻击者所知的pre_master_秘密。pre_master_secret将用于生成master_secret（参见第6.1节）。生成完成的消息、加密密钥和MAC机密需要主密钥（见第5.6.9节和第6.2.2节）。通过发送正确的完成消息，双方证明他们知道正确的pre_master_机密。
Completely anonymous sessions can be established using RSA, Diffie-Hellman, or FORTEZZA 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或FORTEZZA建立，用于密钥交换。使用匿名RSA，客户端使用从服务器密钥交换消息中提取的服务器未经认证的公钥对预主密钥进行加密。结果在客户端密钥交换消息中发送。由于窃听者不知道服务器的私钥，因此他们无法解码pre_master_机密。
With Diffie-Hellman or FORTEZZA, 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) or the FORTEZZA token encryption key (TEK).
对于Diffie Hellman或FORTEZZA，服务器的公共参数包含在服务器密钥交换消息中，而客户端的公共参数则在客户端密钥交换消息中发送。不知道私有值的窃听者应该无法找到Diffie Hellman结果（即pre_master_secret）或FORTEZZA令牌加密密钥（TEK）。
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 or DSS certificate. The signature includes the current
使用RSA，密钥交换和服务器身份验证结合在一起。公钥可以包含在服务器的证书中，也可以是服务器密钥交换消息中发送的临时RSA密钥。使用临时RSA密钥时，它们由服务器的RSA或DSS证书签名。签名包括当前的
ClientHello.random, so old signatures and temporary keys cannot be replayed. Servers may use a single temporary RSA key for multiple negotiation sessions.
因此旧签名和临时密钥无法重放。服务器可以为多个协商会话使用单个临时RSA密钥。
Note: The temporary RSA key option is useful if servers need large certificates but must comply with government-imposed size limits on keys used for key exchange.
注意：如果服务器需要大型证书，但必须遵守政府对用于密钥交换的密钥施加的大小限制，则临时RSA密钥选项非常有用。
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 5.6.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用于密钥交换时，使用证书验证消息对客户端进行身份验证（请参阅第5.6.8节）。客户端对从master_secret和前面所有握手消息派生的值进行签名。这些握手消息包括将签名绑定到服务器的服务器证书和将签名绑定到当前握手过程的ServerHello.random。
When Diffie-Hellman key exchange is used, the server either can supply a certificate containing fixed Diffie-Hellman parameters or can 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证书或未经身份验证，它会在客户机密钥交换消息中向服务器发送一组临时参数，然后可选地使用证书验证消息对自身进行身份验证。
FORTEZZA's design is classified, but at the protocol level it is similar to Diffie-Hellman with fixed public values contained in certificates. The result of the key exchange process is the token encryption key (TEK), which is used to wrap data encryption keys, client write key, server write key, and master secret encryption key. The data encryption keys are not derived from the pre_master_secret because unwrapped keys are not accessible outside the token. The encrypted pre_master_secret is sent to the server in a client key exchange message.
FORTEZZA的设计是保密的，但在协议级别，它类似于Diffie Hellman，证书中包含固定的公共值。密钥交换过程的结果是令牌加密密钥（TEK），用于封装数据加密密钥、客户端写入密钥、服务器写入密钥和主密钥加密密钥。数据加密密钥不是从pre_master_secret派生的，因为在令牌之外无法访问未包装的密钥。加密的pre_master_机密在客户端密钥交换消息中发送到服务器。
Because SSL version 3.0 includes substantial improvements over SSL version 2.0, attackers may try to make version 3.0-capable clients and servers fall back to version 2.0. This attack is occurring if (and only if) two version 3.0-capable parties use an SSL 2.0 handshake.
由于SSL版本3.0包含了对SSL版本2.0的重大改进，攻击者可能会试图使支持版本3.0的客户端和服务器退回到版本2.0。当（且仅当）两个支持3.0版的参与方使用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 be using 40- bit encryption keys anyway. Altering the padding of the least significant 8 bytes of the PKCS padding does not impact security, since this is essentially equivalent to increasing the input block size by 8 bytes.
尽管使用非随机PKCS#1 block type 2消息填充的解决方案并不美观，但它为3.0版服务器提供了一种合理安全的方法来检测攻击。此解决方案不安全，攻击者可以在应用程序指定的等待阈值过期之前强行使用密钥并替换包含相同密钥（但具有正常填充）的新加密密钥数据消息。担心这种规模的攻击的各方无论如何都不应该使用40位加密密钥。更改PKCS填充中最低有效8字节的填充不会影响安全性，因为这实际上相当于将输入块大小增加8字节。
An attacker might try to influence the handshake exchange to make the parties select different encryption algorithms than they would normally choose. Because many implementations will support 40-bit exportable encryption and some may even support null encryption or MAC algorithms, this attack is of particular concern.
攻击者可能试图影响握手交换，使双方选择不同于通常选择的加密算法。由于许多实现将支持40位可导出加密，有些甚至可能支持空加密或MAC算法，因此这种攻击尤其令人担忧。
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 other's 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写入稳定的存储。
SSL 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.
SSL非常保守地使用哈希函数。在可能的情况下，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. FORTEZZA encryption keys are generated by the token, and are not derived from the master_secret.
主密钥使用ClientHello.random和ServerHello.random散列，为每个连接生成唯一的数据加密密钥和MAC密钥。FORTEZZA加密密钥由令牌生成，并且不是从主密钥派生的。
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 SSL 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字段是确保用于一个SSL记录层客户端的消息不会重定向到另一个客户端所必需的。序列号可确保检测到删除或重新排序邮件的尝试。由于序列号的长度为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机密可能大于加密密钥，因此即使加密密钥被破坏，消息也可以保持防篡改。
For SSL 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.
为了使SSL能够提供安全连接，客户端和服务器系统、密钥和应用程序都必须是安全的。此外，实现必须没有安全错误。
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位批量加密密钥和匿名服务器时应格外小心。在决定哪些证书和证书颁发机构是可接受的时，实现和用户必须小心；不诚实的证书颁发机构会造成巨大的损失。
Appendix G. Acknowledgements
附录G.确认书
Martin Abadi Robert Relyea Digital Equipment Corporation Netscape Communications ma@pa.dec.com relyea@netscape.com
马丁·阿巴迪·罗伯特·雷耶数字设备公司网景通信ma@pa.dec.com relyea@netscape.com
Taher Elgamal Jim Roskind Netscape Communications Netscape Communications elgamal@netscape.com jar@netscape.com
Taher Elgamal Jim Roskind Netscape Communications Netscape Communicationselgamal@netscape.com jar@netscape.com
Anil Gangolli Micheal J. Sabin, Ph.D. Netscape Communications Consulting Engineer gangolli@netscape.com msabin@netcom.com
Anil Gangolli Micheal J.Sabin博士。网景通信咨询工程师gangolli@netscape.com msabin@netcom.com
Kipp E.B. Hickman Tom Weinstein Netscape Communications Netscape Communications kipp@netscape.com tomw@netscape.com
Kipp E.B.Hickman Tom Weinstein Netscape Communications Netscape Communicationskipp@netscape.com tomw@netscape.com
Robert Baldwin Clyde Monma RSA Data Security, Inc. Bellcore baldwin@rsa.com clyde@bellcore.com
Robert Baldwin Clyde Monma RSA数据安全公司Bellcorebaldwin@rsa.com clyde@bellcore.com
George Cox Eric Murray Intel Corporation ericm@lne.com cox@ibeam.jf.intel.com
乔治·考克斯埃里克·默里英特尔公司ericm@lne.com cox@ibeam.jf.intel.com
Cheri Dowell Avi Rubin Sun Microsystems Bellcore cheri@eng.sun.com rubin@bellcore.com
Cheri Dowell Avi Rubin太阳微系统公司Bellcorecheri@eng.sun.com rubin@bellcore.com
Stuart Haber Don Stephenson Bellcore Sun Microsystems stuart@bellcore.com don.stephenson@eng.sun.com
斯图尔特·哈伯·唐·斯蒂芬森·贝尔科太阳微系统公司stuart@bellcore.com大学教师。stephenson@eng.sun.com
Burt Kaliski Joe Tardo RSA Data Security, Inc. General Magic burt@rsa.com tardo@genmagic.com
Burt Kaliski Joe Tardo RSA数据安全公司通用魔术burt@rsa.com tardo@genmagic.com
Authors' Addresses
作者地址
Alan O. Freier Netscape Communications
阿兰O弗雷尔网景通信公司
Philip Karlton Netscape Communications
Philip Karlton Netscape通信公司
Paul C. Kocher Independent Consultant
Paul C.Kocher独立顾问