HTTPS相关 - RFC2246[译]

本文为纯机翻，读来并不通顺

请求征求意见：2246 Certicom
类别：Standards Track C. Allen
Certicom
1999年1月TLS协议版本1.0
本备忘录的状态
本文档指定了
Internet社区的Internet标准跟踪协议，并要求讨论和提出建议。
改进。请参阅最新版本的“ Internet
官方协议标准”（STD 1）了解标准化状态

协议的状态。该备忘录的分发是无限的。

版权声明

版权所有（C）互联网协会（1999）。版权所有。

摘要

本文档指定了传输层安全性
（TLS）协议的1.0版。TLS协议提供了
Internet上的通信隐私。该协议允许客户端/服务器应用程序以
旨在防止窃听，
篡改或消息伪造的方式进行通信。

目录

1.简介3
2.目标4
3.本文件的目标5
4.介绍语言5
4.1。基本块大小6
4.2。杂项6
4.3。矢量6
4.4。民数记7
4.5。列举7
4.6。构造类型8
4.6.1。变形9
4.7。密码属性10
4.8。常数11
5. HMAC和伪随机函数11
6. TLS记录协议13
6.1。连接状态14 Dierks＆Allen标准轨道[第1页]

---

RFC 2246               TLS协议版本1.0 1999年1月

6.2。记录层16
6.2.1。碎片16
6.2.2。记录压缩和解压缩17
6.2.3。记录有效载荷保护18
6.2.3.1。空或标准流密码19
6.2.3.2。CBC分组密码19
6.3。密钥计算21
6.3.1。导出密钥生成示例22
7. TLS握手协议23
7.1。更改密码规范协议24
7.2。警报协议24
7.2.1。关闭警报25
7.2.2。错误警报26
7.3。握手协议概述29
7.4。握手协议32
7.4.1。你好消息33
7.4.1.1。您好请求33
7.4.1.2。客户问好34
7.4.1.3。服务器问候36
7.4.2。服务器证书37
7.4.3。服务器密钥交换消息39
7.4.4。证书申请41
7.4.5。服务器问好完成42
7.4.6。客户端证书43
7.4.7。客户端密钥交换消息43
7.4.7.1。RSA加密的
Premaster 机密消息44 7.4.7.2。客户Diffie-Hellman公共价值45
7.4.8。证书验证45
7.4.9。已完成46
8.密码计算47
8.1。计算主密钥47
8.1.1。RSA 48
8.1.2。Diffie-Hellman 48
9.强制密码套件48
10.应用程序数据协议48
A.协议常数值49
A.1。记录层49
A.2。更改密码规格消息50
A.3。警报消息50
A.4。握手协议51
A.4.1。你好消息51
A.4.2。服务器认证和密钥交换消息52
A.4.3。客户端认证和密钥交换消息53
A.4.4。握手完成消息54
A.5。CipherSuite 54
A.6。安全参数56
B.术语表57
C.CipherSuite定义61

Dierks＆Allen标准路线[第2页]

---

RFC 2246               TLS协议版本1.0 1999年1月

D.实施说明64
D.1 临时RSA密钥64
D.2。随机数的产生和播种64
D.3。证书和认证65
D.4。CipherSuites 65
E.与SSL 66
E.1的向后兼容性 版本2客户端问候67
E.2。避免中间人版本回滚68
F.安全分析69
F.1。握手协议69
F.1.1。身份验证和密钥交换69
F.1.1.1。匿名密钥交换69
F.1.1.2。RSA密钥交换和认证70
F.1.1.3。Diffie-Hellman密钥交换与身份验证71
F.1.2。版本回滚攻击71
F.1.3。检测针对握手协议的攻击72
F.1.4。继续会议72
F.1.5。MD5和SHA 72
F.2。保护应用程序数据72
F.3。最后说明73
G.专利声明74
安全考虑75
参考文献75
积分77
评论78
完整的版权声明80 1。简介
TLS协议的主要目标是提供隐私和数据

两个通信应用程序之间的完整性。该协议
由两层组成：TLS记录协议和TLS握手
协议。在最低级别上，
TLS记录协议位于某些可靠的传输协议（例如TCP [TCP]）之上。该
TLS记录协议规定，有两个基本的连接安全
性：

-连接专用。对称加密用于
数据加密（例如DES [ DES ]，RC4 [ RC4 ]等）。
此对称加密的密钥针对每个
连接唯一生成，并且基于另一连接协商的秘密
协议（例如TLS握手协议）。记录
协议也可以不加密使用。

-连接可靠。消息传输包括
使用键控MAC 的消息完整性检查。安全哈希函数（例如
SHA，MD5等）用于MAC计算。记录
协议可以在没有MAC的情况下运行，但通常仅在Dierks＆Allen Standards Track [Page 3]中使用

---

RFC 2246               TLS协议版本1.0（1999年1月）采用

这种方式，而另一种协议使用记录协议作为
协商安全性参数的传输方式。

TLS记录协议用于封装各种更高
级别的协议。一种这样的封装协议TLS握手
协议，允许服务器和客户端进行身份验证，
并
在应用协议发送或接收其第一字节
数据之前协商加密算法和加密密钥。TLS握手协议提供
具有三个基本属性的连接安全性：

-可以使用非对称或
公共密钥密码术（例如RSA [ RSA ]，DSS [ DSS ]等）来验证对等方的身份。该
身份验证可以设置为可选，但通常
至少对等方是必需的。

-共享密钥的协商是安全的：
窃听者无法使用协商后的密钥，对于任何经过身份验证的
连接，即使是
可以将自己置于连接中间的攻击者也无法获取该密钥。

-协商可靠：攻击者
未经双方检测就无法修改协商通信
沟通。

TLS的优点之一是它与应用程序协议无关。
更高级别的协议可以
透明地在TLS协议之上分层。但是，TLS标准未指定
协议如何通过TLS添加安全性；有关如何启动TLS
握手以及如何解释
交换的认证证书的决定，
取决于运行在TLS之上的协议的设计者和实现者的判断。2。目标
TLS协议的目标按照其优先级顺序为：
1.密码安全性：应该使用TLS
在两方之间建立安全连接。

2.互操作性：独立的程序员应该能够
使用TLS开发应用程序，从而能够在
不了解
彼此代码的情况下成功地交换密码参数。

3.可扩展性：TLS寻求提供一个框架，
在
必要时可以将新的公共密钥和批量加密方法并入其中。这还将完成两个子目标：防止Dierks＆Allen Standards跟踪[第4页]

---

RFC 2246               TLS协议版本1.0（1999年1月）

需要创建一个新协议（并冒可能引入
新弱点的风险），并避免实现一个
全新的安全库。

4.相对效率：加密操作倾向于占用大量
CPU，特别是公钥操作。出于这个
原因，TLS协议已经将可选的会话
高速缓存方案，以减少需要连接的数量
必须从头开始建立。此外，已采取措施
减少网络活动。3。本文件目标

本文档和TLS协议本身基于
Netscape发布的SSL 3.0 协议规范。该
协议与SSL 3.0之间的差异并不明显，但它们之间的
差异非常大，以至于TLS 1.0和SSL 3.0不能互操作
（尽管TLS 1.0确实包含了一种机制，TLS
实施可以通过该机制降级到SSL 3.0）。本文档
主要面向将要实施该协议的读者以及对其
进行密码分析的读者。
编写此规范时已考虑到这一点，并且旨在反映
这两个群体的需求。因此，许多依赖于算法的
数据结构和规则包含在文本正文中（与
附录相对），提供了对它们的更轻松访问。
尽管涵盖了某些
策略区域（因为它们需要维护可靠的
安全性），但

本文档无意提供服务定义或接口定义的任何详细信息。4。表示语言
本文档以外部
表示形式处理数据的格式。将使用以下非常基本且有些随意
定义的表示语法。该语法
从其结构的多个来源中提取。尽管它的
语法和XDR 类似于编程语言“ C” [

XDR ]在它的两个
语法和意图，这将是危险的吸引太多的相似之处。该
表示语言的目的仅是记录TLS，而不是
超出特定目标的一般应用。Dierks＆Allen标准路线[第5页]

---

RFC 2246               TLS协议版本1.0，1999年1月

4.1。基本块大小

明确指定所有数据项的表示形式。的
基本数据块的大小是一个字节（即，8个比特）。多个字节数据
项是从左到右，从上到下的字节串联
。从字节流中，通过以下方式形成一个多字节项（
示例中为数字）（使用C表示法）：

value =（byte [0] << 8 *（n-1））| （字节[1] << 8 *（n-2））|
… | 字节[n-1];

多字节值的这种字节顺序是普通网络
字节顺序或大端格式。4.2。杂

注释以“ / *”开头，以“ * /”结尾。

可选组件通过将其
括在“ [[]]”双括号中来表示。

包含未解释数据的单字节实体为
不透明类型。4.3。向量
向量（单维数组）是同类数据
元素的流。向量的大小可以在文档编制
时指定，也可以在运行时不指定。无论哪种情况，长度都
声明
向量中的字节数，而不是元素数。用于指定作为类型T的固定
长度向量的新类型T’的语法为
T T’[n]；

在此，T’在数据流中占据n个字节，其中n是
T的大小的倍数。向量的长度不包括在
编码流中。

在以下示例中，数据被定义为
协议不解释的三个连续字节，而数据被定义为三个
连续的数据，总共消耗9个字节。

不透明的基准面[3]；/ 三个未解释的字节 /
基准数据[9]；/ * 3个连续的3字节向量* / Dierks＆Allen Standards Track [Page 6]

---

RFC 2246               TLS协议版本1.0（1999年1月）

通过
使用<floor…ceiling>标记（包括所有内容）指定合法长度的子范围来定义可变长度向量。当
编码时，实际长度字节中先于矢量的内容
流。长度将采用数字形式，该数字消耗
保持向量指定的最大（上限）
长度所需的字节数。实际长度字段为零的可变长度向量
称为空向量。

T T’<floor…ceiling>;

在下面的示例中，manual是必须包含以下内容的向量
在300到400个字节之间的不透明类型。它永远不能为空。的
实际长度字段占用两个字节，一个UINT16，足以
表示值400（参见第4.4节）。另一方面，更长的时间
可以表示最多800个字节的数据或400个uint16元素，并且它
可能为空。它的编码将包括
在向量之前的两个字节的实际长度字段。编码向量的长度必须
是单个元素长度的偶数倍（例如，
uint16 的17字节向量将是非法的）。

不透明的强制性<300…400>;
/ 长度字段是2个字节，不能为空 ​​/
uint16 long <0…800>;
/ 零到400个16位无符号整数 / 4.4。数字
基本数字数据类型是无符号字节（uint8）。所有较大的
数值数据类型均由固定长度的一系列字节构成
，如第4.1节所述，这些字节串联在一起，并且也没有符号。在
下列数字类型是预定义的。
uint8 uint16 [2];
uint8 uint24 [3];
uint8 uint32 [4];
uint8 uint64 [8];
此处以及规范中其他位置的所有值均以
“网络”或“大端”顺序存储；由十六进制表示的UINT32
字节01 02 03 04等同于十进制值16909060. 4.5

。枚举

另一种稀疏数据类型称为枚举。
enum类型的字段只能采用定义中声明的值。
每个定义都是不同的类型。只能
分配或比较相同类型的枚举。枚举的每个元素都必须Dierks＆Allen Standards Track [Page 7]

---

RFC 2246为               TLS协议版本1.0（1999年1月）