没有合适的资源?快使用搜索试试~ 我知道了~
TLS1.3(RFC8446) - 翻译版 .docx
5星 · 超过95%的资源 需积分: 49 44 下载量 97 浏览量
2021-05-30
22:15:53
上传
评论 4
收藏 165KB DOCX 举报
温馨提示
试读
64页
TLS1.3(RFC8446) - 翻译版 .docx
资源详情
资源评论
资源推荐
TLS 1.3
摘要
本文规定了 协议的 版本。 为 模式应用提供了一种设计为防止监听、篡改和
伪造的 通信方式。
本文为 和 的更新版,淘汰了 、 和 。本文也规
定了实现 的新要求。
1. 介绍
TLS 的主要目标是为通信双方提供一个安全的通道;对下层传输的唯一要求是提供可靠
保序的数据流。安全通道尤其应该提供如下属性:
认证(Authentication):server 端应该总是需要认证的;client 端可
以选择性的认证。认证可以通过非对称算法完成(如 RSA、椭圆曲线
数字签名算法(ECDSA)、或 Edwards 曲线数字签名算法(EdDSA))完
成,或通过对称预共享密钥(PSK)。
保密(Condentiality):在建立好的通道上发送的数据只能终端可
见。TLS 不隐藏传输数据的长度,但终端可以填充 TLS 记录(pad)来
隐藏真实长度,从而提升安全性。
完整性(Integrity):在建立好的通道上发送的数据不能被攻击者修
改(如果修改了一定会被发现)。
即使出现像 RFC3552 那样已经完全控制网络的攻击者,这些属性也应该保证。
更完整的相关安全属性清单详见附录 E。
TLS 由两个主要部分构成:
握手协议(第 4 节),认证通信双方,协商加密模式和参数,并确定共享
密钥。握手协议可以防止篡改,如果连接没有受到攻击,攻击者就不能强
制两端协商不同的参数。
记录协议(第 5 节),使用由握手协议协商出的参数来保护通信双方的流
量。记录协议将流量分为一系列记录,每个记录独立地使用流量密钥保护。
TLS 是一个独立的应用协议;上层协议可以透明地运行于 TLS 之上。然而,TLS 标
准并未指定怎样使用 TLS 保证安全、怎样发起 TLS 握手以及怎样理解认证证书交换,这些
留给运行在 TLS 之上的协议的设计者和实现者来判断。
本文定义了 TLS 1.3. 虽然 TLS 1.3 与以前的版本不直接兼容,但所有 TLS 版本都包含
一个版本控制机制,可以在客户端和服务器都支持的情况下协商出一个公共版本。
本文取代和废除了以前版本的 TLS,包括 1.2 版本[RFC5246]。也废除了在[RFC5077]里
面定义的 TLS ticket 机制,并用定义在第 2.2 节中的机制取代它。由于 TLS 1.3 改变了密钥
的产生方式,它更新了[RFC5705]。正如 7.5 节描述的那样。它也改变了在线证书状态协
议(OCSP)消息的传输方式,因此更新了[RFC6066],废除了[RFC6961],如第 4.4.2.1
节所述。
1.1. 约定和术语
使用了以下术语
客户端()发起 连接的端点。
连接()两端之间的传输层连接。
端点()连接的客户端或者服务器。
握手( ! ")客户端和服务器之间协商 交互的后续参数的出示协商。
对端()一个端点,当说到一个特定端点,对端指的是非当前讨论的端点。
接收端(#)接收记录的端点。
发送者(!)发送记录的端点。
服务器(!#)没有发起 连接的端点。
1.2. 跟 TLS 1.2 的主要区别
以下是 TLS 1.2 和 TLS 1.3 的主要差异。这并不是全部差异,还有很多次
要的差别。
支持的对称算法列表已经删除了所有被认为是遗留问题的算法。列表保留
了所有使用“关联数据的认证加密”(AEAD)算法。密码套件的概念已经改
变,将认证和密钥交换机制与记录保护算法(包括密钥长度)和 Hash(用
于秘钥导出函数和握手消息认证码 MAC)分离。
增加 0-RTT 模式,为一些应用数据在连接建立阶段节省了一次往返,这是
以牺牲一定的安全特性为代价的。
静态 RSA 和 Diffie-Hellman 密码套件已经被删除;所有基于公钥的密钥交
换算法现在都能提供前向安全。
所有 ServerHello 之后的握手消息现在都已经加密。扩展之前在
ServerHello 中以明文发送,新引入的 EncryptedExtension 消息可以保证扩
展以加密方式传输。
密钥导出函数被重新设计。新的设计使得密码学家能够通过改进的密钥分
离特性进行更容易的分析。基于 HMAC 的提取-扩展密钥导出函数
(HKDF)被用作一个基础的原始组件。
Handshake 状态机进行了重大重构,以便更具一致性和删除多余的消息如
ChangeCipherSpec(除了中间件兼容性需要)。
椭圆曲线算法已经属于基本的规范,且包含了新的签名算法,如
EdDSA。TLS 1.3 删除了点格式协商以便于每个曲线使用单点格式。
其它的密码学改进包括改变 RSA 填充以使用 RSA 概率签名方案
(RSASSA-PSS),删除压缩,数字签名算法 DSA,和定制 DHE 组
(Ephemeral Die-Hellman)。
废弃了 TLS1.2 的版本协商机制,以便在扩展中添加版本列表。这增加了不
支持版本协商的 server 的兼容性。
之前版本中会话恢复(根据或不根据 server 端状态)和基于 PSK 的密码族
已经被一个单独的新 PSK 交换所取代。
引用已更新至最新版本的 RFC(例如,RFC 5280 而不是 RFC 3280)。
1.3. 更新影响 TLS1.2
本文提出了几个可能影响 TLS 1.2 实现的变化,包括那些不支持 TLS 1.3 的
实现:
4.1.3 节中的版本降级保护机制。
4.2.3 节中的 RSASSA-PSS 签名方案。
ClientHello 中“supported_versions”扩展可以用于协商 TLS 使用的版本,优
先于 ClientHello 中的 legacy_version 字段。
"signature_algorithms_cert"扩展允许一个 client 声明它使用哪种签名算法
验证 X.509 证书。
此外,本文提出了支持 TLS 的早期版本需要实现的部分;见 9.3 节。
2. 协议概览
安全通道使用的密码参数由 TLS 握手协议生成。这个 TLS 的子协议在 client 和 server
第一次通信时使用。握手协议使两端协商协议版本、选择密码算法、选择性互相认证,并
得到共享的密钥数据。一旦握手完成,双方就会使用得出的密钥保护应用层流量。
握手失败或其它协议错误会触发连接中止,在这之前可以有选择地发送一个警报消息
(第 6 章)。
TLS 支持 3 种基本的密钥交换模式:
(EC)DHE (基于有限域或椭圆曲线的 Diffie-Hellman)
PSK-only
PSK 结合(EC)DHE
图 显示了基本 握手全过程:
#
$%&'
()*+"%,! -
*+!. /, .0!-
*+!","%,) .,0!-
#+,! ,"%-111111112
#'&$%
+"%,! -*()
+,! ,"%-#
剩余63页未读,继续阅读
aashuii
- 粉丝: 53
- 资源: 8
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功
评论5