首先使用wireshark而且打开浏览器,打开百度(百度使用的是HTTPS加密),随意输入关键词浏览。css
我这里将抓到的包进行过滤。过滤规则以下web
ip.addr == 115.239.210.27 && ssl
下面用图来描述一下上面抓包所看到的流程。
算法
打开抓包的详细,以下。
chrome
不难看出,这一握手过程,客户端以明文形式传输了以下信息:浏览器
这一阶段,服务端返回所选择的协议版本(Version),加密套,压缩算法,随机数,Session ID等;服务器
from:https://blog.csdn.net/u010536377/article/details/78989931网络
通过了 SSL 握手后,服务端的身份认证成功,协商出了加密算法为 AES,密钥为 xxxxx(客户端和服务端拿三个随机值用相同算法计算出来的,并无明文传输)。一切准备就绪。session
SSL 握手成功,已经能够对接下来的数据加密了,接下来各类应用层协议均可以加密传输。加密
应用数据传输消息。由于这里是 HTTPS,因此能够对 HTTP 应用协议数据加密而后传输了。spa
Secure Sockets Layer TLSv1.2 Record Layer: Application Data Protocol: http Content Type: Application Data (23) Version: TLS 1.2 (0x0303) Length: 1072 Encrypted Application Data: 6d9b3c9089271630c33506fe28cd6a61fed1f4bd2808f537...
从这里,不知道密钥是没法知道这里传输的是什么数据,连传输的是什么协议的内容都不知道。
因此以前建立 SSL 隧道,让代理服务器盲传 HTTPS 数据,就得经过 CONNECT 方法告诉代理服务器要连哪台主机,哪一个端口号,要否则代理服务器也是一脸懵逼。
因此 SSL 协议是很独立的,这里是对 HTTP 进行了加密,也能够对其余协议进行加密。它就像是 TCP 和应用层协议的中间层,为上层协议提供了加密的数据传输。
SSL 警告消息,由于是加密的内容,因此单从 Wireshark 看不出警报的内容。
Secure Sockets Layer TLSv1.2 Record Layer: Encrypted Alert Content Type: Alert (21) Version: TLS 1.2 (0x0303) Length: 48 Alert Message: Encrypted Alert
但由于警报消息常常只是客户端用来提示服务端 SSL 传输结束,对照抓包到的内容确实如此。因此这里只是 SSL 传输结束的一个信号。
发出了 Encryted Alert 后客户端数据传输完毕,准备进入四次挥手断开 TCP 链接。
密钥交换算法目前经常使用的有RSA和Diffie-Hellman。
对于密钥交换使用RSA算法,pre-master-secret由客户端生成,并使用公钥加密传输给服务器。
对于密钥交换使用Diffie-Hellman算法,pre-master-secret则经过在Key Exchange阶段交换的信息,由各自计算出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解密数据?咱们能够经过下面几种方法来使wireshark能解密https数据包。
1. 中间人攻击;
2. 设置web服务器使用RSA做为交换密钥算法;
3. 若是是用chrome,firefox,能够设置导出pre-master-secret log,而后wireshark设置pre-master-secret log路径,这样就能够解密了。