零基础也能懂!Wireshark 为啥解不开 HTTPS?3 分钟搞懂原理 + 搞定它
当前位置:点晴教程→知识管理交流
→『 技术文档交流 』
介绍加密技术 协议解析 中间人攻击 流程![]() 问题 为了精准定位一个技术难题,我们在服务器端运用tcpdump工具捕获了HTTPS数据包,并将这些数据包传输至本地计算机。随后,使用wireshark软件对数据包进行深入分析。在这个过程中,我们尝试下载并配置了目标域名的私钥至wireshark中,但遗憾的是,数据包依然无法被成功解密。我们怀疑是wireshark的密钥配置方法存在错误,尽管我们查阅了大量相关文献,这些资料都指明了正确的配置步骤。由于我们对HTTPS协议的理解尚浅,一时难以找到解决问题的突破口。因此,我们决定先从了解TLS协议入手,于是仔细研读了TLS1.2版本的RFC文档,最终总算勉强解开了这个疑惑。 TLS握手整个过程 在着手处理这个议题之前,我们首先需要全面审视TLS握手流程的整体架构。在此过程中,一些相对罕见或次要的环节已被简化或省略,具体情况可参考下图所示。 ![]() 下面按顺序介绍各握手步骤。 Client Hello 这标志着TLS握手协议的起始阶段,其发起方为客户端。在这一步中,客户端会发送一个包含随机数(该随机数将用于后续生成会话密钥)以及其所能支持的加密套件清单的信息。具体内容如图所示: ![]() Server Hello 服务器收到客户端的Client Hello数据包之后,根据客户端发来的加密套件列表,选择一个加密套件,也生成一个随机字符串返回给客户端。我们看到下图中的加密套件为,密钥交换算法使用ECDHE_RSA,对称加密算法使用AES_256_GCM_SHA384,如图: ![]() Server Certificate 随后服务器会继续发送包含证书链以及域名证书在内的证书清单。这些返回的证书数据旨在让客户端能够验证当前所连接服务器的真实身份,从而有效防御中间人攻击行为。 Server Key Exchange Server Key Exchange协议包,由服务器返回,主要目的是与客户端交换用于数据对称加密的密钥。如图: ![]() Server Hello Done 服务器端向客户端发送此协议数据,用以通知客户端已完成返回用于密钥交换的相关数据。在此之后,服务器端将等待客户端的响应。 Client Key Exchange 客户端在接收到服务器所返回的DH密钥数据后,会利用这些数据生成自身的DH公共数据,并将此生成的DH公共数据发送回服务器,双方均以此为基础来共同生成最终的pre-master-secret密钥。具体流程如下图所示: ![]() Change Cipher Spec 此协议用于客户端和服务器相互告知也完成密钥交换过程,可以切换到对称加密过程。 到此,基础的TLS握手流程已经基本完成。为了深入探究本文所探讨的问题,我们接下来需要进一步熟悉密钥交换机制,并且掌握RSA以及Diffie–Hellman这两种常见的密钥交换算法。 密钥交换算法 密钥交换算法目前常用的有RSA和Diffie-Hellman。 对于密钥交换使用RSA算法,pre-master-secret由客户端生成,并使用公钥加密传输给服务器。 采用Diffie-Hellman算法进行密钥交换的过程中,pre-master-secret的生成是基于双方在密钥交换阶段所交换的信息,各自独立计算得出的。因此,pre-master-secret并不会被存储在硬盘上,也不会通过网络进行传输,这也就意味着使用wireshark等工具无法捕获到session key,从而无法解密应用层数据。那么,我们是否有可能反向推导出pre-master-secret呢?从理论上讲,这是可行的,但实际上,这个过程非常困难。 对Diffie-Hellman算法感兴趣的可以参考https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman\_key\_exchange 解决方法 尽管我们已经探讨了诸多相关内容,但核心问题依然存在:究竟有哪些可行策略能够帮助Wireshark成功解密数据?为了实现这一目标,特别是针对HTTPS数据包的解密,我们可以借助以下几种具体方法来增强Wireshark的功能。 1. 中间人攻击; 2. 设置web服务器使用RSA作为交换密钥算法; 3. 如果您正在使用Chrome或Firefox浏览器,您可以通过配置导出pre-master-secret日志文件。接着,在Wireshark中设置该日志文件的路径,这样您便能够成功解密相应的网络流量。 阅读原文:原文链接 该文章在 2026/1/4 18:14:45 编辑过 |
关键字查询
相关文章
正在查询... |