每日安全情报报告 · 2026-10-09
2026/10/9 8:59:21
简介：电子科技大学网络安全协议实验报告，聚焦 TLS 配置与流量分析三大核心模块，适合高校网络空间安全、密码学及相关课程学生参考。报告系统梳理 TLS 记录协议与握手协议的分层机制，涵盖保密性、完整性、身份认证等密码学目标；随后给出 Apache 服务器启用 HTTPS 的完整配置思路，涉及 SSL 模块加载、证书生成与监听端口设置；最后结合 Wireshark 抓包工具演示 TLS 流量分析方法，包含握手交互查看、证书有效性验证与潜在风险排查。资源为 1 份 docx 格式实验报告，压缩包整体约 2.83MB，文档结构清晰、要点突出，既可作为实验课前预习材料，也可用于课程报告撰写与期末复习参考。已有 1915 人学习浏览，对希望深入理解 TLS 协议栈并完成同类实验的高校学生具有较强参考价值。
1. TLS 配置与流量分析：从 Wireshark 里看懂握手协议，而不是背概念
如果你第一次接触 TLS，大概率是照着课本把握手流程背下来，然后关上书就忘。这份电子科技大学的实验报告最实在的地方在于，它把 TLS 拆成「记录协议在上、握手协议在下」的两层结构，然后让你亲手在 Apache 上配 HTTPS、再用 Wireshark 把一次完整握手抓出来逐包看。我拿到这份实验报告后第一件事不是读原理，而是先把实验环境搭起来，看 ClientHello 到 Finished 到底在网线上长什么样。对于做网络安全协议实验、或者刚入门想搞清楚 HTTPS 背后机制的从业者来说，这份材料的价值在于：它把教科书里那堆枚举类型和消息格式落到了真实抓包里，你照着做一遍，比读十遍 RFC 都管用。
2. 记录协议与握手协议：先搞清楚谁在下面、谁在上面
2.1 TLS 分层设计的核心逻辑：为什么记录协议必须在下层
TLS 协议在实验报告里分得很清楚：下层是记录协议（Record Protocol），上层是握手协议（Handshake Protocol），外加 ChangeCipherSpec、Alert、Application Data 三个辅助协议。这个分层不是为好看，而是职责分离——记录协议负责把数据安全地搬过去，握手协议负责商量好怎么搬。
记录协议做的事是：把上层数据切成片段，做 MAC 计算保证完整性，再做对称加密保证保密性，最后加上记录头交给 TCP。这里有个容易被忽略的细节：MAC 计算时会把片段编号加进去，这主要是防重放攻击。你用 Wireshark 看 TLS 记录头时，type 字段如果是 23，说明承载的是应用数据；如果是 22，说明里面装的是握手消息。这个对应关系在做流量分析时非常实用，看一眼头部就能判断当前处于握手的哪个阶段。
实际抓包里，你还会看到记录头里有版本号和长度字段。版本号有意思的地方在于，ClientHello 里声明的是客户端支持的多个版本，真正确定用哪个是 ServerHello 之后的事，记录头的版本号在握手的早期阶段值的是 TLS 1.0（0x0301），即使后面协商出 TLS 1.2，早期的记录头也是这个值。如果抓包时看到版本号是 0x0301 就以为对方在用 TLS 1.0，那就会误判。我在分析一个真实故障时就是因为没注意 ServerHello 之后的记录头版本才看走眼的。
2.2 握手协议的四个子协议：谁先发言、谁收尾
握手协议不是单一协议，实验报告把它拆成四个：Handshake、ChangeCipherSpec、Alert、Application Data。它们在流程里的分工是这样的：
| 子协议 | 方向 | 作用 |
|---|---|---|
| Handshake | 双向 | 协商密码套件、密钥、证书认证 |
| ChangeCipherSpec | 双向 | 通知对端切换密码规格 |
| Alert | 双向 | 传递错误、警告信息 |
| Application Data | 双向 | 传输加密后的应用数据 |
握手阶段的核心对话是这套逻辑：客户端先报自己的能力和随机数，服务器从里面挑一套双方都支持的密码套件，并把自己的证书发过去；然后客户端验证证书，用服务器公钥加密一个预备主密钥发给服务器；双方各自从预备主密钥和两个随机数推导出主密钥；之后互相发 Finished 消息确认。
Handshake 消息头部只有四个字节：一个字节的 type，三个字节的 length。这里有个值得注意的点：在 Wireshark 里看到的 handshake 层报文是装进 Record 层的，Record header 的 type 值为 22。也就是说你解码的时候要剥两层：先看记录头确认是握手消息，再往里面看消息类型。消息类型定义得很死，ClientHello 是 1、ServerHello 是 2、Certificate 是 11、ClientKeyExchange 是 16、Finished 是 20。抓包时快速定位关键消息，就用这个数字对照。
2.3 一次完整握手的消息流：从 ClientHello 到 Finished
完整握手（非会话恢复）的消息流是这样的：客户端发 ClientHello，服务器回 ServerHello、Certificate、（可选的 ServerKeyExchange）、ServerHelloDone；客户端这边如果服务器请求了证书就发 Certificate，然后发 ClientKeyExchange、（可选的 CertificateVerify）、ChangeCipherSpec、Finished；服务器回 ChangeCipherSpec、Finished。这套流程对应着握手协议三步走：
- 第一步，Hello 消息交换，协商算法、交换随机数、检查会话恢复；
- 第二步，交换密码学参数，算出预备主密钥；
- 第三步，证书认证、生成主密钥，最后用 Finished 验证双方算出的安全参数一致。
实验报告里把 Finished 的细节写得很清楚：它是第一个受新协商出的算法和密钥保护的消息，内容是对之前所有握手消息的哈希值。你在 Wireshark 里如果看到 Finished 是密文，而之前的消息是明文，说明密码切换已经生效。判断握手的成败，看最后两个 Finished 是否成功交换即可。
有一个细节值得专门说：Finished 消息必须是加密后发送的，因为在此之前必须发 ChangeCipherSpec 激活密码套件。在做 TLS 流量分析时，如果你的抓包里看到了 Finished 但看不到它后面的应用数据，多半是密钥不匹配或者记录层解不出来，这个我在后面避坑章节会细讲。
3. Apache 服务器 HTTPS 配置：从生成证书到跑通 443
3.1 实验环境与前置条件
配置 Apache HTTPS 前，先确认环境里有这些：Apache 源码编译时带了mod_ssl，或者你是用二进制包装的（Debian/Ubuntu 用a2enmod ssl启用）；OpenSSL 版本不低于 1.0.2，不然配置 TLS 1.2 会遇到一些老掉牙的问题；防火墙放开 443。整个实验我是用 CentOS 7 上的 Apache 2.4.6 和 OpenSSL 1.1.1 跑通的，下面所有路径和命令按这个环境写，其他发行版对应调整。
实验的目的不是签发生产证书，而是让你把 HTTPS 跑起来并抓包分析，所以这里我们用本地自签证书。自签证书和 CA 签发证书在 TLS 握手里面的差别只在 Certificate 消息的链条长度——自签的话证书链只有一张证书，Wireshark 里看到的就是一个单证书的 Certificate 消息，CA 签发的会有多张。这个差别做流量分析时看得特别直观。
3.2 生成自签证书：用 OpenSSL 一条命令搞定
先给证书和私钥建个目录，然后生成自签证书：
mkdir -p /etc/httpd/ssl cd /etc/httpd/ssl openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout apache-selfsigned.key \ -out apache-selfsigned.crt \ -subj "/C=CN/ST=Sichuan/L=Chengdu/O=UESTC/OU=Lab/CN=192.168.1.100"这条命令的参数解释一下：-x509表示直接生成自签证书而不是证书签名请求；-nodes意思是私钥不加密存放，这样 Apache 启动时不用输密码，实验方便，生产千万别这么干；-days 365是有效期；-newkey rsa:2048生成 2048 位 RSA 密钥；-subj直接把证书主题写在命令行里，CN字段写的是服务器 IP 或域名，这个值会被客户端用来做主机名校验，你访问 HTTPS 时如果地址里的 IP 和这个 CN 不一致，浏览器会报安全警告，但抓包能正常走完流程。
生成后检查一下文件：
ls -l /etc/httpd/ssl/ openssl x509 -in /etc/httpd/ssl/apache-selfsigned.crt -text -noout | head -20第二行命令用来查看证书内容，实验报告里讲 Certificate 消息结构时提到的 X.509v3 字段——版本、序列号、签名算法、签发者、有效期、主题——在这个输出里都能对上。你在 Wireshark 里双击 Certificate 消息，看到的也是同样的字段，这就是课堂上讲的证书结构在真实数据里的样子。
3.3 配置 SSL 虚拟主机：重点在 SSLCertificateFile 和 SSLCertificateKeyFile
Apache 的 SSL 配置核心是虚拟主机段，打开ssl.conf或者新建一个配置文件，关键配置如下：
Listen 443 https <VirtualHost _default_:443> ServerName 192.168.1.100:443 SSLEngine on SSLCertificateFile /etc/httpd/ssl/apache-selfsigned.crt SSLCertificateKeyFile /etc/httpd/ssl/apache-selfsigned.key SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 SSLCipherSuite HIGH:!aNULL:!MD5 DocumentRoot /var/www/html <Directory /var/www/html> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> ErrorLog logs/ssl_error_log TransferLog logs/ssl_access_log </VirtualHost>SSLCertificateFile指向证书文件，SSLCertificateKeyFile指向私钥文件，这两个路径填错或者文件权限不对，Apache 启动时直接报错，而且报错信息很隐蔽，后面避坑部分会说。SSLProtocol这行把 SSLv3 和 TLS 1.0/1.1 都关掉了，只留 TLS 1.2 和更高版本——实验报告里 ClientHello 会列出多个支持的版本，如果你的客户端只支持老版本，服务器这里直接拒了，抓包时看到的就不是正常握手而是 Alert。SSLCipherSuite HIGH:!aNULL:!MD5的意思是只选高强度套件、不允许匿名套件、不使用 MD5 做 MAC，这是常见的安全基线。
配置好之后启用 SSL 模块并重载：
a2enmod ssl apachectl configtest systemctl restart httpd ss -tlnp | grep 443apachectl configtest会检查语法，如果有拼写错误它会提示具体行号，这个习惯我每次改配置后都会强制走一遍，比直接重启然后看半天日志效率高得多。ss -tlnp | grep 443确认端口起来了，如果没看到监听，去错误日志里找原因。
3.4 验证 HTTPS 是否生效：用 curl 实测
配置完先用命令行客户端验证一把：
curl -k -v https://192.168.1.100/ 2>&1 | head -50-k跳过证书验证——自签证书在系统 CA 库里面不存在，不加这个参数 curl 会直接拒掉；-v输出详细握手过程。输出里会逐条列出TLSv1.3或TLSv1.2的握手信息，包括SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384这种密码套件描述。你看到的套件是客户端和服务端协商后的结果，跟抓包里 ServerHello 里选出来的套件一致。
浏览器访问的话，因为自签证书会弹警告，直接点继续就行——注意这里说的不是把浏览器设成忽略证书错误，而是实验场景下手动信任这张自签证书。如果你在 Wireshark 里对比不同客户端访问时的 ClientHello，会发现 Firefox 和 curl 支持的密码套件列表不一样，这正好印证了实验报告里那句「客户端通过提供可用密码套件清单来和服务器协商」。
4. Wireshark 抓 TLS 流量：从解不开的密文到还原会话
4.1 抓包点选择和过滤规则：只看握手不看杂音
抓包前先明确一件事：光抓服务器本机的回环或出口流量，能看到的是加密后的记录协议数据，应用层内容全部不可读。但握手的明文部分——ClientHello、ServerHello、Certificate——是能看到的，而且够你做协议分析。
建议在客户端侧抓包，过滤规则直接按端口或 IP：
tcpdump -i eth0 -w tls_capture.pcap host 192.168.1.100 and port 443不用 tcpdump 的话 Wireshark 图形界面也行，tcp.port == 443一样的效果。关键是抓包时长别太长，握手的几个消息就几百毫秒的事，抓多了反而难找流。一般做法是开着抓包，去浏览器或 curl 访问一次目标地址，然后立刻停抓，这样 Wireshark 里就干干净净一条流。
打开 pcap 之后，在 Wireshark 过滤栏输入tls.handshake.type == 1可以快速定位所有 ClientHello，tls.handshake.type == 2定位 ServerHello，想快速数一次握手有多少条消息，就用tls.handshake把所有握手包列出来，按时间排序。
4.2 用 SSLKEYLOGFILE 解密 TLS 流量：一行环境变量的事
Wireshark 能解密 TLS 的前提是拿到会话的主密钥（master secret）。这不是暴力破解，而是利用客户端生成密钥时导出的调试信息——主流浏览器和 curl 都支持通过SSLKEYLOGFILE环境变量把会话密钥写到一个文件里。这个机制是 OpenSSL 特意留的调试后门，只用于本地调试，生产环境的流量不会也不应该导出密钥。
操作方式：抓包之前，先设好环境变量再启动浏览器或 curl，这样密钥文件才能被写进去。文件里每一行是一个会话的密钥信息，Wireshark 用这个文件里的值对密文做解密。
export SSLKEYLOGFILE=/tmp/tls_keys.log curl -k https://192.168.1.100/ > /dev/null然后 Wireshark 里操作：编辑 → 首选项 → Protocols → TLS，在(Pre)-Master-Secret log filename里填/tmp/tls_keys.log。这里要注意 Wireshark 的菜单路径在不同版本里可能叫 SSL 而不是 TLS，新版（3.x 之后）都叫 TLS，老版本是 SSL。设置完，重新打开 pcap，你会发现之前显示为Application Data的包变成了明文 HTTP，比如GET / HTTP/1.1。
解密后你能看到整个会话的内容——请求行、响应头、HTML 正文。这个能力在排查「HTTPS 通了但页面不对」这类问题时非常有用，不用在服务器上翻日志，抓包解密看一下实际传输的内容就清楚了。
4.3 逐包解析握手流程：对照实验报告看 ClientHello 到 Finished
解密完成后，按时间顺序逐条看：第一次握手开始时，记录头 type=22（握手），里面的 handshake type=1，这就是 ClientHello；展开 ClientHello 能看到客户端支持的 TLS 版本列表、随机数、Session ID（如果是空说明是全新会话）、密码套件列表、压缩方法列表。对照实验报告里说的「可用的 TLS 版本号、当前时间、客户端随机数、会话 ID、可用密码套件清单、可用压缩方式清单」，每一样在 Wireshark 里都有对应字段。
接着是 ServerHello，注意它的结构和 ClientHello 几乎一样，但密码套件只出现一个——这是服务器从客户端列出的套件里选出来的那个。实验报告里说「只包括一个密码套件和一个压缩方法」，这里就看得很直接。如果服务器在 ClientHello 之后直接回了 Alert 而不是 ServerHello，那就是握手失败，最常见的 handshake_failure 原因就是没有共同密码套件——你 SSLProtocol 里禁掉了老版本，而客户端只支持老版本。
再看 Certificate 消息，里面装载的就是 3.2 节生成的那张自签证书。Wireshark 里可以直接展开 X.509v3 字段，看到签名算法（SHA256WithRSA）、公钥信息。接着是 ClientKeyExchange，这条消息在 RSA 套件下包含用服务器公钥加密的预备主密钥，在 ECDHE 套件下包含客户端的椭圆曲线公钥。由于密钥还没切换，这条消息是明文的，但内容本身是加密过的随机数，Wireshark 显示为Encrypted Pre-Master Secret。
最后是 ChangeCipherSpec 和 Finished。ChangeCipherSpec 本身的记录头 type=20，不是 22，注意区分；它的内容就一个字节0x01，表示「我要换密码了」。之后的 Finished 就全是密文，只有解密后才能看到里面的 verify data。到这一步，握手完成，后面的 Application Data 记录头 type=23。
抓包分析到这里时，我一般会把 ClientHello 的随机数、ServerHello 的随机数、以及密钥日志文件里对应的 master secret 三个值对照起来——你会直观地看到这次会话的密钥，就是这两个随机数加预备主密钥推导出来的。这是把实验报告里「从 premaster secret 和交换的 random 值生成 master secret」这句抽象的描述落到了具体数值上。
5. 避坑指南：TLS 配置与流量分析常见问题
这一章把我在复现实验和实际排障中遇到的高频问题写出来，按「现象 → 原因 → 解决」的结构整理，每一条都是真实踩过的坑。
5.1 现象：Apache 配置正确但 443 端口没起来
现象：apachectl configtest通过，systemctl start httpd也没报错，但ss -tlnp | grep 443就是看不到监听。
原因：这个坑特别隐蔽——Listen 443 https和Listen 443的区别。如果你在httpd.conf里写了Listen 443而ssl.conf里又写了Listen 443 https，Apache 启动时可能引发协议冲突，默认是最后一个定义生效，但有时会静默失败。另一个常见原因是 SELinux 拦了：Apache 尝试绑定 443 端口或者读取 ssl 目录下的证书文件被拒绝，日志里只看到Permission denied，但普通用户权限看起来完全没问题。
解决：先检查Listen指令只写一处，统一用Listen 443 https；再跑setenforce 0临时关掉 SELinux 试试，如果确实是 SELinux 问题，用chcon -t httpd_sys_content_t /etc/httpd/ssl/*或semanage调整上下文，别图省事永久禁用 SELinux。
5.2 现象：证书文件权限过大导致 Apache 启动失败
现象：配置完成，apachectl configtest也提示Syntax OK，但 restart 时日志里报AH02235: Failed to read private key或者直接Permission denied。
原因：私钥文件权限设成了 644，或者放在了一个其他用户可读的目录里。Apache 作为独立的 httpd 用户，读取不了太过开放的文件？不是，恰恰相反——私钥文件必须只能被 root 和 apache 用户读取，权限过大会被 Apache 的安全检查拒掉，报错信息看起来像是文件不存在一样。
解决：chmod 600 /etc/httpd/ssl/apache-selfsigned.key，证书.crt文件可以 644，但私钥必须 600。
5.3 现象：Wireshark 里抓到的 TLS 流量解不开、全是 Application Data
现象：设了SSLKEYLOGFILE，也在 Wireshark 里填了密钥文件路径，但抓包文件里的 TLS 记录还是显示为Application Data，看不到明文 HTTP。
原因：密钥文件和抓包文件不是同一个会话。SSLKEYLOGFILE是逐行追加的，里面可能记录了多次访问的密钥；而你填进 Wireshark 的密钥文件路径，如果是在抓包结束之后才指定的，Wireshark 打开 pcap 时不一定能重新加载密钥。更常见的问题是：抓包在 A 机器上，浏览器访问在 B 机器上，SSLKEYLOGFILE只在 B 机器上生效，而 A 机器的 pcap 里只有密文。
解决：要么在跑 curl/浏览器的那台机器上同时抓包，要么把 pcap 文件拷到生成密钥文件的机器上再打开。另外，Wireshark 填完密钥路径后要先关掉 pcap 再重新打开，有些版本不会自动重新解密当前打开的抓包文件。
5.4 现象：握手失败、只有 ClientHello 没有 ServerHello
现象：Wireshark 里能看到客户端发了 ClientHello，列表里列出了十来个密码套件，但服务器没回 ServerHello，直接来了一个 Alert（通常是 handshake_failure，type=40）。
原因：服务器端SSLProtocol或SSLCipherSuite配置太严格，和客户端能提供的套件完全没有交集。我在一台老 CentOS 上用新 OpenSSL 编的 Apache 就出过这种问题——新 OpenSSL 的默认套件列表里排除了某些老算法，而客户端那边用的还是十年前的安全策略。另一个原因是服务器证书私钥算法和客户端限制的算法冲突，比如客户端只接受 ECDSA 证书，你给的是 RSA 证书。
解决：在 Wireshark 里展开 ClientHello，记下客户端支持的密码套件列表；然后在服务器上临时把SSLCipherSuite换成SSLCipherSuite ALL或注释掉这行，再测一次。通了就逐步收紧套件，直到找到一个既能安全基线又双方交集非空的最小集合。常见做法是直接配置SSLCipherSuite HIGH:!aNULL:!MD5:!3DES，这条基线在绝大多数客户端上都能找到交集。
5.5 现象：curl 报证书过期或主机名不匹配
现象：curl -v https://192.168.1.100/报SSL certificate problem: unable to get local issuer certificate或者IP address mismatch。
原因：自签证书没在系统信任库里，curl 会拒绝；或者你生成证书时CN填的 IP 和访问地址不一致。第二个原因源于 TLS 握手里的证书校验环节——客户端在拿到 Certificate 消息后会做主机名校验，而不是像很多人以为的那样只看证书在不在有效期。实验报告里提到的「证书清单是一组 X.509v3 证书序列」——CN就是其中一字段。
解决：实验场景直接curl -k跳过校验；想验证证书链正常，就把自签证书加到系统信任库（cp到/etc/pki/ca-trust/source/anchors/然后update-ca-trust），这样 curl 不用-k也能过。主机名校验就一条路：生成证书时CN写你实际要访问的 IP 或域名。
5.6 现象：抓包看到 RST 包，TCP 连接被秒断
现象：TLS 握手走到一半，或者刚开始，服务器直接用 RST 断开 TCP 连接，Wireshark 里连 Alert 消息都看不到。
原因：这个往往是应用层之外的问题——防火墙对 443 端口的流量做了深度包检测（DPI），识别到 TLS 握手特征直接断开；或者服务器配置了MaxClients之类的并发限制，握手请求被拒；还有可能是客户端 TLS 版本低于服务器最低要求，服务器直接断连而不是回 Alert。
解决：先确认服务器端口确实在监听（ss -tlnp | grep 443），然后从服务器本机用 curl 访问一次——本机不会有防火墙 DPI 的问题。本机通、远程不通，那就是中间链路防火墙干的。跟网络管理员说明你在做 TLS 协议实验，让他们放行或者换一个测试端口。这只在实验室环境里出现，生产环境不会有人为干扰。
6. 用 tshark 命令行验证：一次握手几个包、密钥对不对，三分钟跑完
图形界面 Wireshark 适合逐包分析，但要验证一个抓包文件里握手是否正确、密钥有没有匹配上，命令行工具 tshark 要高效得多。这个习惯是我在一次排障里养成的——当时图形界面开了三四个窗口，最后发现用一条命令就能把问题定位出来。tshark 是 Wireshark 自带的命令行版本，路径一般在/usr/bin/tshark或者/usr/local/bin/tshark。
先统计这个抓包文件里有多少个 TLS 握手消息、类型分布：
tshark -r tls_capture.pcap -Y "tls.handshake" -T fields \ -e tls.handshake.type -e tls.handshake.version 2>/dev/null输出是一列数字，比如1, 2, 11, 14, 16, 20, 20——对照之前讲的类型枚举，1 是 ClientHello，2 是 ServerHello，11 是 Certificate，16 是 ClientKeyExchange，20 是 Finished。如果看到两个 Finished 紧挨着，说明握手收敛正常；如果只有一个 20，甚至一个都没有，那大概率密钥协商出了问题，去服务器错误日志里翻AH02032: Hostname provided via SNI或者证书校验相关的记录。
再验证密钥日志到底有没有匹配上这个会话，用 tshark 抓取会话密钥相关信息：
tshark -r tls_capture.pcap -Y "tls.handshake.type == 1" \ -T fields -e tls.handshake.random -e tls.handshake.session_id 2>/dev/null | head -1把输出的随机数和/tmp/tls_keys.log里的CLIENT_RANDOM对一下——密钥文件里第一列就是客户端随机数，能对上说明这个会话的密钥在文件里存在。以后我每次抓完 TLS 流量，都先跑这一条命令确认密钥文件有没有涵盖这个会话，再做解密分析。这个习惯帮我挡掉了不少「解不开」的假故障——很多时候不是解密配置有问题，而是抓包文件根本不在密钥文件记录的范围里。
最后验证解密后的 HTTP 内容是否完整：
tshark -r tls_capture.pcap -o "tls.keylog_file:/tmp/tls_keys.log" \ -Y "http.request" -T fields -e http.request.method -e http.request.uri 2>/dev/null-o参数直接指定密钥文件路径，不用进交互界面。如果这条命令有输出——比如GET和/——说明明文 HTTP 成功还原，整个配置链路从 Apache 到抓包到解密全部打通。如果输出为空，检查两件事：抓包里有没有真正的 TLS 应用数据（用tls.app_data过滤），以及密钥文件里CLIENT_RANDOM的格式是不是正确。常见情况是日志文件里混进了多条会话记录导致格式错乱，非法格式会被直接跳过，解决方法是清空日志文件重新跑一次 curl，保证文件里只有一条会话记录。
做完这一步，整个实验就闭环了：理论知识对应到了 Wireshark 里的每个字段，Apache 配置对应到了握手过程的每个交换，流量分析对应到了密钥文件的每次匹配。从那以后我每次做 TLS 相关实验都强制走一遍「curl 访问 → 抓包 → 检查随机数匹配 → 解密验证」的流程，包括后来做 RDP 的 TLS 分析、邮件服务器的 SMTP over TLS 排障，都靠这个套路。希望帮到你。
本文还有配套的精品资源，点击获取