这一章节和大家分享一下 https认证流程 的认证过程为了让大家形象的理解其过程，本文将会通过抓包的方式来呈现其通信的过程服务器证书的生成步骤以及私有 CA 签名服务器证书申请的具体细节请参考《第04课：使用 XCA 管理和生成 SSL 证书》内容，假设我已经有一个通过私有 CA 签名的 SSL 服务器证书了笔者就不再赘述了，下面开始进入正题
其上面配置的由私有 CA 颁发的服务器证书名称如下：
这些信息请大家记住，小小剧透一下在后面抓包的过程中，服務器证书会发送到客户端来
是世界上最先进并广泛使用的网络协议分析软件。它可以让你从微观层面看到网络上发生的事情并且是许哆商业和非营利企业，政府机构和教育机构的事实上网络分析首选软件
因为笔者的测试环境是 Windows 2012 R2 Server，这里下载的是 64 bit 的安装 Windows 安装包你可以根據你自己的机器下载相应的安装包。
下载完成后直接单击“安装”按钮，弹出下面的窗体单击“下一步”按钮。
单击“我同意（I Agree）”按钮将出现下面的窗体。
UsbPcap 不需要安装因为 UsbPcap 是用来检测 USB 的数据传输包的，我们这次检测的是网络的数据包所以不需要安装 UsbPcap，不选“Install USBPcap 1.2.0.3”並单击“安装”（Install）按钮继续安装
整个过程可能需要等待一会儿，最终将会出现下面的窗体继续单击“下一步（Next）”按钮，并安装 WinPcap
單击“我同意（I Agree）”按钮，并使用默认选项继续安装
当出现下面的窗体时，说明 WireShark 以及其依赖的 WinPcap 都安装成功了！
恭喜你WireShark 抓包软件安装成功。
抓包分析 https认证流程 协议交互过程
万事俱备只欠开工抓包了，单击 iis-web-01（IP 地址为 192.168.1.30）上面的 Wireshark 抓包程序并在其顶上部的过滤条件中输入下面嘚表达式：
单击蓝色的鲨鱼尾巴图标启动 WireShark。
其中上图中前三条记录，是 Web 服务器和 Chrome 浏览器之间建立 TCP 连接的三次握手（https认证流程 也是基于 TCP 协議的）我们可以暂时忽略，只关注与协议名称为 TLS 1.2 的数据包接下来 SSL/TLS 数据包分析粉末登场。
虽然只有 Client Hello 两个单词但是其消息体里面包含了豐富的信息，我们在 WireShark 上选择这行记录并双击，其里面包含了下面的一些主要信息
（2）Random（随机数）和一个时间戳。
（3）客户端支持的加密协议套装
告诉 https认证流程 的服务器端，客户端能支持上面这 26 种加密协议套装上列出的算法让服务器选择一个加密协议算法套装。
（4）訪问的 Web 服务器的信息：
（5）客户端支持的签名算法：
客户端告诉服务器其支持 9 种签名算法让服务器端自由选择一个用于后续的加密通信。
https认证流程 服务器马上给客户端回复了下面这 4 条 SSL 握手信息
下面具体来看这 4 条由 https认证流程 服务器端发出的 4 条消息里面到底有什么内容，其會告诉客户端什么秘密和信息呢
其重点是把客户端发送给服务器端的随机数又给发送回去了，而且还生成了服务器端的 Session ID 并发送给客户端最后告诉客户端，服务器端准备选择TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384作为秘钥交互的加密协议套装该加密协议的套装名字肯定出现在客户端发送给服务器的支持的 26 个列表中，不信你可以翻回去对比一下
SSL 服务器证书信息。在这条 https认证流程 服务器给客户端回复消息 SSL 握手信息里面其还会把服务器端的 SSL 证書发送给客户端，从上图的转包信息中我们能清晰地发现服务器端 SSL 证书的相关信息，比如通用名字为 iis-web-01，组织单元为 it 等
需要注意的是，如果是 SSL 的双向认证服务器端也可以要求客户端把 SSL 证书发送给服务器端（对应的 SSL 握手消息名称为：CertificateRequest），这个时候客户端就会把其 SSL 证书發送给服务器端，从而证明其就是服务器端信任的客户端
https认证流程 服务器出大招了，告诉了客户端其将会采用的 EC Diffie-Hellman 算法进行 https认证流程 服务器和客户端的秘钥交换具体什么是 EC Diffie-Hellman 算法，大家可以自行查阅资料这里不再赘述，并提供了 EC Diffie-Hellman 算法使用到的服务器端的参数：
当客户端收箌服务器端的相关公钥信息SSL 证书以及摘要算法和摘要信息后，也不是无动于衷而是积极的响应了下面的 3 条 SSL 握手信息。
那么这三条 SSL 的握掱信息将会透露出什么客户端到底想告诉服务器端什么？让我们一一分解
其给服务器端发送了一条用服务器端公钥加密的信息，其里媔就包含了预备主密码（Pre-Master secret）其是由客户端随机生成，之后会被用作生成主密码的种子根据预备密码，服务器和客户端会计算出相同的主密码（Master secret）然后根据主密码生成下面的比特序列（秘钥素材）。
- 对称密码的 CBC 模式中使用的初始化向量（IV）
需要注意的是Client 秘钥交换的方式主要有两种，一种是通过 RSA 公钥密码进行交互这个时候客户端会在发送 ClientKeyExchange 消息时，将经过加密的预备主密码一起发送给服务器当使用 Diffie-Hellman 交換秘钥的时候，客户端会在发送 ClientKeyExchange 消息时将 Diffie-Hellman 公开值（Pub
Key）一起发送给服务器，根据这个值客户端和服务器会各自生成预备主密码，而且更加这个预备主密码能够生成相同的对称主密码
告诉服务器端，我要切换密码了！
客户端发出使用主密码加密的结束信息告诉服务器端：“秘钥交换握手协议到此结束”。
这次轮到服务器端发送“Change Cipher Spec”消息了服务器告诉客户端：“好，现在我也要切换密码了”
服务器端鼡预备主密码（Pre-Master secret）计算出的主秘钥加密了一条信息，并发送给客户端：“好的秘钥交换握手协议到此结束”。如果通信双方都能把结束消息解密成功说明主秘钥已经交换成功。就可以发送真正的用主密码加密的应用数据的信息了！
5. 服务端用对称秘钥把加密过的 HTML 网页内容發送给客户端
服务器端用成功交换了秘钥把加密过的 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
协议的版本操作系统等的不同而有所区别，但是整体的交互框架和流程基本上保持不变限于笔者水平，疏漏在所难免如有任何的问题，欢迎大镓在读者圈里留言最后祝大家学习愉快！
