开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 开发测试 -> 用Wireshark看见TLS握手过程 -> 正文阅读

[开发测试]用Wireshark看见TLS握手过程

摘要

第一部分：介绍TLS握手协议内容。（非常粗略的介绍，详见《图解密码技术》-- 结城浩 – 第14章 SSL/TLS 为了更安全的通信）

第二部分：安装wireshark，使用其进行抓数据包，为后面TLS分析做准备。

第三步：详细查看TLS握手的每一步。最后使用一个示例验证握手过程的掌握情况。

TLS握手协议介绍

本节来源：《图解密码技术》-- 结城浩 – 第14章 SSL/TLS 为了更安全的通信

TLS 协议是由 TLS 记录协议 ( TLS record protocol) 和 TLS 握手协议 ( TLS handshake protocol) 这两层协议叠加而成的。

TLS 握手协议分为下列 4 个子协议：握手协议、密码规格变更协议、警告协议和应用数据协议。

在这里插入图片描述

握手协议是 TLS 握手协议的一部分，负责生成共享密钥以及交换证书。其中，生成共享密钥是为了进行密码通信，交换证书是为了通信双方相互进行认证。

握手协议的过程如下图所示。

在这里插入图片描述

下一节，我们通过抓包，验证这张图片中的握手过程。

准备工作

安装wireshark

参考：Ubuntu 上 Wireshark 的安装与使用

sudo apt install wireshark # 选择yes，表允许非超级用户捕获数据包
sudo usermod -aG wireshark $(whoami)
reboot

wireshark的使用

参考：wireShark的基本用法

我的抓包需求：

抓取的内容流进enp2s0接口。
抓取dst和src为www.baidu.com的内容。

所以，wireshark输入设置如下。

在这里插入图片描述

我们使用openssl-s_client，作为客户端程序。(不使用浏览器是避免一些不必要的干扰)

openssl s_client -connect www.baidu.com:443

wireshark抓取内容如下：

在这里插入图片描述

看见TLS握手过程

（0）TCP的三次握手

前三个数据包是TCP的三次握手过程，感兴趣的话，可以阅读实战！我用 Wireshark 让你“看见“ TCP

（1）Client Hello (客户端–>服务器）

在这里插入图片描述

其中的密码套件，拉出来，单独介绍下。

密码套件含义：SSL/TLS 提供了一种密码通信的框架，这意味着 SSL/TLS 中使用的对称密码、公钥密码、数字签名、单向散列函数等技术，都是可以像零件一样进行替换的。也就是说，如果发现现在所使用的某个密码技术存在弱点，那么只要将这一部分进行替换就可以了。尽管如此，也并不是说所有的组件都可以自由选择。由千实际进行对话的客户端和服务器必须使用相同的密码技术才能进行通信，因此如果选择过于自由，就难以确保整体的兼容性。为此， SSL/TLS 就像事先搭配好的盒饭一样，规定了一些密码技术的“推荐套餐＂，这种推荐套餐称为密码套件 (cipher suite)。(来源：《图解密码技术》14.2.6)

密码套件-wiki中的参考链接7–TLS/SSL (Schannel SSP) 中的密码套件，内容不错，我搬运下。

密码套件是一组加密算法。 TLS/SSL 协议的 schannel SSP 实现使用密码套件中的算法来创建密钥和加密信息。密码套件为以下每种任务指定一种算法：

密钥交换算法：保护创建共享密钥所需的信息。这些算法是非对称的，并且对于相对较少的数据性能良好。
批量加密算法：对客户端和服务器之间交换的消息进行加密。这些算法是对称的，适用于大量数据。
消息验证算法：生成消息哈希和签名，以确保消息的完整性。

开发人员通过使用ALG_ID数据类型来指定这些元素。

密码套件名称结构，如下图所示。

在这里插入图片描述

可以看到TLS_AES_256_GCM_SHA384套件，不符合密码套件的名称结构。参考TLS-mozilla，推测没有密钥交换算法，可能表示密钥交换算法可以任意。这样的好处是，避免有太多的密码套件名称。

至于每个套件的具体含义，我不知道到。遇到一个查一个呗。

(2) Server Hello (客户端<–服务器）

服务器给客户端发送的内容：使用的版本号，当前时间，服务器随机数，会话 ID，使用的密码套件，使用的压缩方式

在这里插入图片描述

新建立的会话，Session id length是0。参考SSL_get_session，当session还存在时，ssl 会话包含重新建立连接所需的所有信息，无需完全握手。（有点类似与web中的session）

我们来看下TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256密码套件：

TLS：Transport Layer Security 协议
ECDHE：Elliptic Curve Diffie-Hellman Ephemeral 密钥交换算法。关于Diffie-Hellman，可以参考《图解密码技术》11.5。使用这种算法，通信双方仅通过交换一些可以公开的信息就能够生成出共享的秘密数字，而这一秘密数字就可以被用作对称密码的密钥。（这里用于计算预主密钥）

注：下图是DHE算法，ECDHE是它的改进版。但两者的输入和输出应该是一样的。这里贴下DHE算法的示意图。
RSA：签名使用的非对称算法。对两个hello的随机数和服务端(或客户端)的DH随机数，进行签名。表明自己拥有对应证书的私钥。（RSA是在下方使用的，签名过程也在下方）
AES_128_GCM：对称加密，加密消息流。GCM可以提供对消息的加密和完整性校验。
SHA256：计算消息认证码(Message Authentication Code，MAC)。计算位置应该是下图位置。

~~接下来的Certificate, Server Key Exchange, Server Hello Done在一个数据包中，从服务端发送到客户端。为了清晰起见，我们分开来看。~~

（3） Certificate (客户端<–服务器）

服务器向客户端发送证书清单。证书清单是一组 X.509v3 证书序列，首先发送的是服务器（发送方）的证书，然后会按顺序发送对服务器证书签名的认证机构的证书。客户端会对服务器发送过来的证书进行验证。

在这里插入图片描述

（4）ServerKeyExchange (客户端<–服务器）

当 Certificate 消息不足以满足需求时，服务器会通过 ServerKeyExchange 消息向客户端发送一些必要信息。

具体所发送的信息内容会根据所使用的密码套件而有所不同。

当不需要这些信息时，将不会发送 ServerKeyExchange 消息。

在这里插入图片描述

上图的Pubkey应该是ECDHE算法需要的两个随机数中的一个。使用rsa算法，对client hello 的随机值，server hello 的随机值，Pubkey值进行签名，表明服务端有对应证书的私钥。

（5）CertificateRequest (客户端<–服务器）

服务端要看客户端的证书。访问百度，不需要对客户端进行认证，所以没有该消息。

（6）ServerHelloDone (客户端<–服务器）

表示从 ServerHello 消息开始的一系列消息的结束。

在这里插入图片描述

(7) Certificate (客户端–>服务器）

服务器读取客应端的证书并进行验证。当服务器没有发送 CertificateRequest 消息时，客户端不会发送 Certificate 消息。所以，没有该消息。

~~接下来的Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message在一个数据包中。为了清晰起见，我们分开来看。~~

（8）ClientKeyExchange (客户端–>服务器）

当密码套件中包含 RSA 时，会随 ClientKeyExchange 消息一起发送经过加密的预备主密码。
当密码套件中包含趴ffie-Hellman 密钥交换时，会随 ClientKeyExchange 消息一起发送 Diffie-Hellman 的公开值。

在这里插入图片描述

（9） CertificateVerify (客户端–>服务器）

客户端只有在服务器发送 CertificateRequest 消息时才会发送 CertificateVerify 消息。这个消息的目的是向服务器证明自己的确持有客户端证书的私钥。所以，没有该消息。

（10）ChangeCipherSpec (客户端–>服务器）

实际上， ChangeCipherSpec 消息并不是握手协议的消息，而是密码规格变更协议的消息。

在 ChangeCipherSpec 消息之前，客户端和服务器之间已经交换了所有关于密码套件的信息，因此在收到这一消息时，客户端和服务器会同时切换密码。

在这一消息之后， TLS 记录协议就开始使用双方协商决定的密码通信方式了。

在这里插入图片描述

（11）Encrypted Handshake Message (客户端–>服务器）

参考： Encrypted Handshake Message、TLS/SSL 协议详解 (19) Encrypted handshake message

The TLS handshake is concluded with the two parties sending a hash of the complete handshake exchange, in order to ensure that a middleman did not try to conduct a downgrade attack.

1.这个报文的目的就是告诉对端自己在整个握手过程中收到了什么数据，发送了什么数据。来保证中间没人篡改报文。
2.其次，这个报文作用就是确认秘钥的正确性。因为Encrypted handshake message是使用对称秘钥进行加密的第一个报文，如果这个报文加解密校验成功，那么就说明对称秘钥是正确的。(来自：https://blog.csdn.net/foshengtang/article/details/109066047)

在这里插入图片描述

~~接下来的New Session Ticket, Change Cipher Spec, Encrypted Handshake Message在一个数据包中。为了清晰起见，我们分开来看。~~

（12）New Session Ticket (客户端<–服务器）

参考：Session Ticket

我们来看下它的流程，首先客户端在ClientHello的扩展中带上session_ticket扩展表示它想使用session_ticket功能，服务端如果同意则在ServerHello中回复session_ticket扩展项。服务端不用保存session，而是加密之后通过NewSessionTicket消息发送给客户端。这里session ticket key实际上是个对称密钥，它只有服务端自己知道。

后续客户端想要重用该Session，在ClientHello扩展中把之前那个session_ticket塞进去，服务端成功解密且验证通过之后就进行会话重用，否则回退到完整的握手。然后还是同样地根据主密钥重新派生出会话密钥。

这样服务端没有了保存session的负担，但是天下没有免费的午餐，session ticket对前向安全性会带来一定的损害。因为session ticket只是单纯使用session ticket key进行加密的，如果session ticket key泄漏了，那么之前基于会话重用的握手就都可以被破解了。

所以在实际使用时，session ticket key应该经常更换，减小前向安全性方面的风险。

在这里插入图片描述