使用wireshark对HTTPS解密的实践(一)--测试结果
最近需要解析HTTPS流量,所以对wireshark的HTTPS解密进行了实测。网上各种文章很多,但是具体操作起来还是很多没讲清楚的,自己做完记录一下。
最开始总是解密不出来,后来找到官网的文章才发现对解密是有限制的。使用wireshark解密SSL协议的限制如下文:
https://wiki.wireshark.org/TLS#RSA_Keys
https://wiki.wireshark.org/SampleCaptures#SSL_with_decryption_keys
TLS Decryption
Wireshark supports TLS decryption when appropriate secrets are provided. The two available methods are
Key log file using per-session secrets (#Using_the_.28Pre.29-Master-Secret).
Decryption using an RSA private key (#RSA_Keys).
A key log file is a universal mechanism that always enables decryption, even if a Diffie-Hellman (DH) key exchange is in use. The RSA private key only works in a limited number of cases.
The key log file is a text file generated by applications such as Firefox, Chrome and curl when the SSLKEYLOGFILE environment variable is set. To be precise, their underlying library (NSS, OpenSSL or boringssl) writes the required per-session secrets to a file. This file can subsequently be configured in Wireshark (#Using_the_.28Pre.29-Master-Secret).
The RSA private key file can only be used in the following circumstances
The cipher suite selected by the server is not using (EC)DHE.
The protocol version is SSLv3, (D)TLS 1.0-1.2. It does not work with TLS 1.3.
The private key matches the server certificate. It does not work with the client certificate, nor the Certificate Authority (CA) certificate.
The session has not been resumed. The handshake must include the ClientKeyExchange handshake message.
The key log file is generally recommended since it works in all cases, but requires the continuous ability to export the secrets from either the client or server application. The only advantage of the RSA private key is that it needs to be configured only once in Wireshark to enable decryption, subject to the above limitations.
我自己测试的结果是:
一、使用wireshark解密https的方法
方法一:
1、在wireshark的首选项中的protocols的tls选项里添加服务器私钥文件。p12文件需要填写密码。
2、从整个会话开始前开始抓包。
3、https数据包自动解密为http格式的包。
方法二:
1、使用chrome浏览器浏览页面,在系统环境变量中设置SSLKEYLOGFILE=C:\ssl_key\sslog.log(可变),将对应的文件同时添加到的首选项中的protocols的tls选项。
2、抓包,https数据包自动解密为http格式的包。
二、方法一解密限制
1、私钥文件
文件格式只能是pem、p12、pfx、key,其中pem文件的必须是PKCS#12格式,且需要把前缀删除。
私钥文件必须与服务器端证书文件相匹配,即使用私钥文件生成服务器证书。
2、必须从整个会话起始抓取,因为每个步骤的包都要抓到才能解密出来会话**。
3、加密协议只能使用SSLv3或(D)TLS 1.0-1.2。
目前最高版本是TLSv1.3,是18年8月发布的。目前大部分浏览器默认按最高TLSv1.3来连接。但服务器可以设置使用的协议版本范围,设置成TLSv1.2,试了下baidu、360、qq、taobao、工商银行的https连接抓包,都是用的TLSv1.2。
TLSv1.3新版本功能里有几项是:
通过在(EC)DH**协议期间使用临时**来保证完善的前向安全性。
放弃许多不安全或过时特性的支持,包括数据压缩、重新协商、非AEAD密码本、静态RSA和静态DH**交换、自定义DHE分组、点格式协商、更改密码本规范的协议、UNIX时间的Hello消息,以及长度字段AD输入到AEAD密码本。
禁止用于向后兼容性的SSL和RC4协商。
个人理解这个就是相当于放弃使用RSA算法交换**,所以基于下一条,不支持TLSv1.3。
4、不能使用(EC)DHE算法交换**
SSL会话建立过程由服务器端决定**交换算法,client hello会提供可选的**交换算法,服务器在server hello时选择最终使用的算法。
试了下客户端提供的算法有例如下图,提供的**交换算法都是ECDHE或者RSA。目前默认会选择ECDHE,因为RSA**交换存在漏洞不安全。
服务器端(以tomcat为例)可以指定支持的cipher suit,从而限定**交换算法范围。
试了一些网站,使用的都是ECDHE**交换算法,wireshark不支持。
三、方法二解密限制
使用key log file log的方式,即记录会话Pre-Master-Secret的方式不存在这些方法一的相关限制。但是不能使用旁路的方式获取会话加***,需要在服务器端或者客户端处获取。
先把结论写到这里,具体的涉及到的其他内容,后面再写。