SSL/TLS 协议运行机制概述(二)

SSL/TLS 协议运行机制概述(二)

SSL/TLS 协议运行机制概述(一)中介绍了TLS 1.2 的运行机制,现在我们来看年 TLS 1.3 的运行机制。会涉及到SSL/TLS 协议运行机制概述(一)中的一些概念,有需要的可以配合着看。

TLS 1.3 握手过程

TLS 1.3 握手过程

  1. 与 TLS 1.2 握手一样,"Client Hello" 消息启动握手,但这次它包含了很多信息。TLS 1.3 将支持的密码套件从37个减少到5个。在握手的上下文中,这意味着客户端除了从它猜测的任何协议发送密钥共享外,还可以猜测将使用什么密钥协议/交换协议。
  2. 服务器将用自己的 "Server Hello" 消息响应。就像1.2握手一样,它也会在此时发送证书。并且,如果客户机猜对了,并且两端同意相同的 AEAD 协议,服务器将发送自己的密钥共享部分,计算会话密钥(session key),并以 "Server Finished" 消息结束。
  3. 现在客户端已经拥有了所有相关信息,客户端将对 SSL 证书进行身份验证,并使用这两个密钥共享来计算它自己的会话密钥副本。完成后,它会发送自己的完成消息。

TLS 1.3 握手相对 TLS 1.2 的改进

  1. 更少的往返次数

最理想的情况是,TLS 1.2握手可以进行两次往返。在某些情况下,可能需要额外的往返行程,因此我们是在最佳情况下所讨论的往返行程的数量。对比如下两个图:

TLS 1.2 握手

TLS 1.2 握手

TLS 1.3 握手

TLS 1.3 握手

相比之下,TLS 1.3 的握手只是一次往返旅行

  1. 简化密码套件

TLS 1.2 支持的密码套件有37个,到目前为止有些已经很不安全了,而且过多的配置会导致过分的复杂,因此 TLS 1.3 将支持的密码套件从37个减少到5个。往返次数的减少归结于密码套件支持的减少。
最值得注意的是,关于密钥交换的整个选择都被删除了。Diffie-Hellman Ephemeral 方案是TLS 1.3 的唯一选择,它允许客户端在握手的第一部分将其密钥共享信息与 Client Hello 一起发送。RSA 加密与所有其他静态密钥交换方案一起被完全删除。完美前向保密(PFS)已经成为 TLS 1.3 的一项要求。

  1. 零往返恢复(Zero Round Trip Resumption, 0-RTT)

TLS握手在历史上一直很昂贵:增加服务器的负载和增加连接的延迟。所以缩小它的想法很有吸引力。0-RTT 只是通过存储一些有关客户端的秘密信息来实现这一点,通常是会话 ID (Session ID) 或会话票证(Session Tickets),以便将来双方连接时使用。

尽管0-RTT带来了所有好处,但它实际上也带来了一些潜在的问题。
(1) 它使客户端容易受到重播攻击。在重播攻击中,以某种方式设法访问加密会话的攻击者可以获取 0-RTT 数据(包括客户端的第一个请求),并将其再次发送到服务器,它可以欺骗服务器,因为它无法知道数据来自哪里。如果攻击者多次发送这个请求,就称为“重放攻击”。当然,它并不像听起来那么容易,有一些机制可以阻止这种攻击。

(2)更大的问题是,0-RTT 握手可能通过提供解密旧会话的途径破坏完美前向保密(PFS)。当然,通过定期轮换会话密钥可以轻松避免这种情况。

  1. 保护更多的 TLS 1.3 握手

在握手的早期,最大的担心之一是它的明文发送量。在 TLS 1.2 握手中,握手的协商阶段是不安全的,而是使用一个简单的 MAC 来确保没有人篡改传输的内容。TLS 1.3 握手对早期部分进行了数字签名(对 ServerHello 消息之后的握手信息加密),这使得握手更安全,减少了降级攻击。这还提供了一种途径,通过验证私钥的拥有情况来更快速有效地对服务器进行身份验证。

参考链接:

https://www.thesslstore.com/blog/explaining-ssl-handshake/
https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4

posted @ 2020-03-15 18:48  二十亿光年的孤独  阅读(446)  评论(0编辑  收藏  举报