第09课:HTTPS

第09课:HTTPS 的认证过程详解

这一章节和大家分享一下 HTTPS 的认证过程,为了让大家形象的理解其过程,本文将会通过抓包的方式来呈现其通信的过程。服务器证书的生成步骤以及私有 CA 签名服务器证书申请的具体细节请参考《第04课:使用 XCA 管理和生成 SSL 证书》内容,假设我已经有一个通过私有 CA 签名的 SSL 服务器证书了,笔者就不再赘述了,下面开始进入正题。

环境准备

1. 服务器准备

假设我们有两台服务器,iis-web-01(IP 地址为 192.168.1.30)和 iis-web-02(IP 地址为 192.168.1.4),我们将在 iis-web-01 服务器上部署一个基于 HTTPS 的一个 Web 应用,然后在 iis-web-02 服务器上安装一个 Chrome 浏览器作为客户端,来访问部署在 iis-web-01(IP 地址为 192.168.1.30)服务器上的 HTTPS 一个 Web 应用,网站的内容如下:

enter image description here

其上面配置的由私有 CA 颁发的服务器证书名称如下:

  • 服务器证书名称:iis-web-01;
  • 颁发服务器证书的 CA 名称:51TalkDocter Root CA。

enter image description here

这些信息请大家记住,小小剧透一下,在后面抓包的过程中,服务器证书会发送到客户端来。

2. WireShark 抓包软件准备

为了能够重现服务器端和客户端整个 SSL 通信的交互过程,我将在 iis-web-01(IP 地址为 192.168.1.30)机器上安装 WireShark。Wireshark 的发展得益于全球网络专家的志愿者贡献,其是 Gerald Combs 在 1998 年开始的一个项目的延续。Wireshark 是世界上最先进并广泛使用的网络协议分析软件。它可以让你从微观层面看到网络上发生的事情,并且是许多商业和非营利企业,政府机构和教育机构的事实上网络分析首选软件。

WireShark 的官方网站我们可以下载 WireShark 安装包。

enter image description here

因为笔者的测试环境是 Windows 2012 R2 Server,这里下载的是 64 bit 的安装 Windows 安装包,你可以根据你自己的机器下载相应的安装包。

下载完成后,直接单击“安装”按钮,弹出下面的窗体,单击“下一步”按钮。

enter image description here

单击“我同意(I Agree)”按钮,将出现下面的窗体。

enter image description here

全选所有的选项。

enter image description here

选择下面的配置。

enter image description here

选择默认的安装路径。

enter image description here

选择安装 WinPcap。因为 Wireshark 基于 Winpcap 处理网络驱动层,Winpcap 是 Libpcap 在 Windows 上的对应物,Winpcap 的开发包 Wpdpack 可以用来做很多事情,比如分析截包什么的,所以 WinPcap 是需要安装的。

enter image description here

UsbPcap 不需要安装,因为 UsbPcap 是用来检测 USB 的数据传输包的,我们这次检测的是网络的数据包,所以不需要安装 UsbPcap,不选“Install USBPcap 1.2.0.3”并单击“安装”(Install)按钮继续安装。

enter image description here

整个过程可能需要等待一会儿,最终将会出现下面的窗体,继续单击“下一步(Next)”按钮,并安装 WinPcap。

enter image description here

单击“我同意(I Agree)”按钮,并使用默认选项继续安装。

enter image description here

最后 WinPcap 安装成功。

enter image description here

WireShark 继续安装。

enter image description here

当出现下面的窗体时,说明 WireShark 以及其依赖的 WinPcap 都安装成功了!

enter image description here

此时如果“运行 WireShark 2.4.6 64 位”(Run WireShark 2.4.6 64-bit)复选框被选中,当单击“完成(Finish)按钮”时,则会自动打开 WireShark。

enter image description here

恭喜你,WireShark 抓包软件安装成功。

抓包分析 HTTPS 协议交互过程

万事俱备,只欠开工抓包了,单击 iis-web-01(IP 地址为 192.168.1.30)上面的 Wireshark 抓包程序,并在其顶上部的过滤条件中输入下面的表达式:

(ip.src_host ==192.168.1.30  && ip.dst_host == 192.168.1.4 ) || (ip.src_host ==192.168.1.4  && ip.dst_host == 192.168.1.30 )

其意思是指抓取 IP 地址为 192.168.1.30 和 192.168.1.4 两台机器上的通信信息,其中 192.168.1.30 为 Web 服务器端,192.168.1.4 为浏览器端。

单击蓝色的鲨鱼尾巴图标启动 WireShark。

enter image description here

然后在 192.168.1.30 启动浏览器并在浏览器中输入 https://192.168.1.30,此时,服务器端 WireShark 将会把整个通信过程记录下来,如下图所示意。

enter image description here

其中,上图中前三条记录,是 Web 服务器和 Chrome 浏览器之间建立 TCP 连接的三次握手(HTTPS 也是基于 TCP 协议的),我们可以暂时忽略,只关注与协议名称为 TLS 1.2 的数据包,接下来 SSL/TLS 数据包分析粉末登场。

1. 客户端首先向服务器端发送一个 Client Hello 的 SSL 握手信息。

enter image description here

虽然只有 Client Hello 两个单词,但是其消息体里面包含了丰富的信息,我们在 WireShark 上选择这行记录,并双击,其里面包含了下面的一些主要信息。

enter image description here

(1)Handshake Type:Client Hello(握手类型)。

(2)Random(随机数)和一个时间戳。

enter image description here

(3)客户端支持的加密协议套装。

enter image description here

告诉 HTTPS 的服务器端,客户端能支持上面这 26 种加密协议套装上列出的算法,让服务器选择一个加密协议算法套装。

(4)访问的 Web 服务器的信息:

enter image description here

(5)客户端支持的签名算法:

enter image description here

客户端告诉服务器其支持 9 种签名算法,让服务器端自由选择一个用于后续的加密通信。

2. HTTPS 服务器马上给客户端回复 4 条 SSL 握手信息

enter image description here

HTTPS 服务器马上给客户端回复了下面这 4 条 SSL 握手信息。

  • Server Hello
  • Certificate
  • Server Key Exchange Server
  • Hello Done

下面具体来看这 4 条由 HTTPS 服务器端发出的 4 条消息里面到底有什么内容,其会告诉客户端什么秘密和信息呢?

(1)Server Hello SSL 握手信息

enter image description here

其重点是把客户端发送给服务器端的随机数又给发送回去了,而且还生成了服务器端的 Session ID 并发送给客户端,最后告诉客户端,服务器端准备选择TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384作为秘钥交互的加密协议套装,该加密协议的套装名字肯定出现在客户端发送给服务器的支持的 26 个列表中,不信你可以翻回去对比一下。

(2)Certificate

enter image description here

SSL 服务器证书信息。在这条 HTTPS 服务器给客户端回复消息 SSL 握手信息里面,其还会把服务器端的 SSL 证书发送给客户端,从上图的转包信息中,我们能清晰地发现服务器端 SSL 证书的相关信息,比如,通用名字为 iis-web-01,组织单元为 it 等。

需要注意的是,如果是 SSL 的双向认证,服务器端也可以要求客户端把 SSL 证书发送给服务器端(对应的 SSL 握手消息名称为:CertificateRequest),这个时候,客户端就会把其 SSL 证书发送给服务器端,从而证明其就是服务器端信任的客户端。

(3)Server Key Exchange 握手消息

enter image description here

HTTPS 服务器出大招了,告诉了客户端其将会采用的 EC Diffie-Hellman 算法进行 HTTPS 服务器和客户端的秘钥交换。具体什么是 EC Diffie-Hellman 算法,大家可以自行查阅资料,这里不再赘述,并提供了 EC Diffie-Hellman 算法使用到的服务器端的参数:

  • 曲线类型:named_curve: secp256r1
  • 公钥信息
  • 签名的算法:rsa_pkcs1_sha1
  • 签名的信息

(4)Server Hello Done 握手信息

握手信息列表结束了。

enter image description here

3. HTTPS 客户端马上给服务器端回复 3 条 SSL 握手信息

当客户端收到服务器端的相关公钥信息,SSL 证书以及摘要算法和摘要信息后,也不是无动于衷,而是积极的响应了下面的 3 条 SSL 握手信息。

enter image description here

  • Client Key Exchange
  • Change Cipher Spec
  • Encrypted Handshake Message

那么这三条 SSL 的握手信息将会透露出什么?客户端到底想告诉服务器端什么?让我们一一分解。

(1)Client Key Exchange 握手信息

enter image description here

其给服务器端发送了一条用服务器端公钥加密的信息,其里面就包含了预备主密码(Pre-Master secret),其是由客户端随机生成,之后会被用作生成主密码的种子。根据预备密码,服务器和客户端会计算出相同的主密码(Master secret),然后根据主密码生成下面的比特序列(秘钥素材)。

  • 对称密码的秘钥
  • 消息认证码的秘钥
  • 对称密码的 CBC 模式中使用的初始化向量(IV)

需要注意的是,Client 秘钥交换的方式主要有两种,一种是通过 RSA 公钥密码进行交互,这个时候客户端会在发送 ClientKeyExchange 消息时,将经过加密的预备主密码一起发送给服务器。当使用 Diffie-Hellman 交换秘钥的时候,客户端会在发送 ClientKeyExchange 消息时,将 Diffie-Hellman 公开值(Pub Key)一起发送给服务器,根据这个值,客户端和服务器会各自生成预备主密码,而且更加这个预备主密码能够生成相同的对称主密码。

(2)Change Cipher Spec 握手信息

enter image description here

告诉服务器端,我要切换密码了!

(3)Encrypted Handshake Message 握手信息

enter image description here

客户端发出使用主密码加密的结束信息,告诉服务器端:“秘钥交换握手协议到此结束”。

4. HTTPS 服务端马上给客户端回复 2 条 SSL 握手信息

enter image description here

这次轮到服务器端发送“Change Cipher Spec”消息了,服务器告诉客户端:“好,现在我也要切换密码了”。

服务器端用预备主密码(Pre-Master secret)计算出的主秘钥加密了一条信息,并发送给客户端:“好的,秘钥交换握手协议到此结束”。如果通信双方都能把结束消息解密成功,说明主秘钥已经交换成功。就可以发送真正的用主密码加密的应用数据的信息了!

5. 服务端用对称秘钥把加密过的 HTML 网页内容发送给客户端

enter image description here

服务器端用成功交换了秘钥把加密过的 HTML 网页内容发送给客户端,客户端用以前收到过的对称秘钥进行解密,HTTPS 通信协议圆满结束。

请读者注意,上面的步骤只是把我当前环境下抓取到的使用 TL S1.2 协议规范进行了 HTTPS 通信原理和过程的梳理和解释,在不同的环境下,其通信过程会有一些差异,比如,如果配置了双向 SSL 认证,其 SSL 服务器端还会要求客户端把客户端的证书发送到服务端,从而验证客户端是否是可信任的,另外在进行主密码交换的过程中,也可能采用 RSA 公钥密码,而不是 Diffie-Hellman,此时,其 SSL 握手消息会有所不同,但是整体的流程和交互过程思路基本上保持相同。

总结

本文通过 WireShark 转包工具生动形象的展示了使用 HTTPS 进行通信的时候,HTTPS 协议是如何通过 SSL 协议来进行秘钥交换的,其在交换秘钥前进行了一系列的协商,比如非对称加密的加密套件,信息摘要的算法,同时服务器也把服务端的证书发给了客户端,给客户端一个机会来确认是否服务器端的 SSL 证书是否可信,如果可信的话,就继续进行对称秘钥的交换,如果不可信,客户端可以随时终止 HTTPS 的通信,这就是为什么当我们用浏览器访问一个不受信任的 CA 签发的证书或者自签名证书的时候,其会弹出一个警告框的原因,此时客户端可以选择强制继续,也能选择终止。

希望本篇文章能够给读者起到抛砖引玉的作用,拓宽大家的思路,并真正意义上形象的理解了 HTTPS 的通信过程,读者在实际用 WireShark 进行抓包的过程中,得到的网络包信息会因为浏览器,HTTPS Web 服务器,SSL/TLS 协议的版本,操作系统等的不同而有所区别,但是整体的交互框架和流程基本上保持不变。限于笔者水平,疏漏在所难免,如有任何的问题,欢迎大家在读者圈里留言。最后祝大家学习愉快!

上一篇
下一篇
目录