使用wireshark分析https

Author Avatar
WoodyXiong 3月 30, 2018
  • 在其它设备中阅读本文章

从上文中分析了http的抓包使用wireshark分析http,接下来想继续分析https于是搭建了https的环境。现在开始使用wireshark抓包软件分析https。


https交互的大致步骤

密码学算法

要了解https首先要稍微了解算法学的知识,在这里主要是RSA算法和DES算法,作为工科,我觉得不需要十分了解算法内部的实现,只需要了解用法即可。下面就谈谈我对这两种算法的大致理解。

RSA算法


通过RSA可以得到两个秘钥,一个是A,一个是B,两个可以互补

使用秘钥A加密的密文,只有用B才能解开

使用秘钥B加密的密文,只有用A才能解开

使用A可以推到出B,使用B不能推到出A 参考链接1 参考链接2

A是私钥,不能公开;B是公钥,可以公开

优点:公钥可以随意公开;缺点:非对称加密,运算量较大


通过上述对RSA算法的简要概括,可以分析运用RSA的一些日常使用的功能。

首先是数据的加密,假设我是服务端,利用RSA算法算出了私钥A和公钥B,将公钥B公开出去,私钥A我自己保存起来。只要别人和我通信,都是用公钥B将数据加密,但是只有我拥有私钥A,所以就只有我能看到数据的原始内容;尽管大家都拥有公钥B,但是都不能解开这个数据。这样就实现了数据的加密功能。

其次用到的功能是数字签名,用来验证数据的源头是否是那个人。假设我是数据的源头,利用RSA算法算出了私钥A和公钥B,将公钥B公开出去,私钥A我自己保存起来。我是数据源头,需要对外发送数据,首先用Hash函数给数据生成数字摘要,然后用私钥对数字摘要进行加密,这样就生成了“数字签名”,然后我将数字签名加在要发送的数据之后,这样就完成了签名操作。接收方接收到数据之后,首先使用公钥对签名进行解密,然后用Hash函数给数据生成数字摘要,最后将生成的数字摘要和解密的数据进行对比,如果与之对应则说明发送源头是私钥的所有者。这样就进行了对数据源头的验证。数字签名是什么

DES算法

对称加密即加密方和解密方使用一样的秘钥,大家都通过这个秘钥进行加密和解密。

优点:运算速度快;缺点:双方的秘钥都不能泄露

Diffie-Hellman算法

此算法的作用是通信双方在不安全的信道上面共享一个秘钥,并且只有通信双方知道秘钥的内容。通常用在传输DES对称加密的秘钥。

使用wireshark抓包

抓包准备

为了让第一次握手的数据存在,抓包之前要清楚浏览器的缓存,然后直接输入域名进行访问,用wireshark的ip过滤之后的抓包如下图所示。
抓包

http重定向

由于是直接访问域名,Apache服务器有重定向的功能直接跳转到了https模式,由于http的包比较简单,所以就简要描述一下。

12、13、14、14 tcp/ip连接的创建

17、20 http相应,返回的是301重定向

重定向

71、72、73、74 与http服务断开连接

分析https

为了更好的分析https,我们直接过滤443端口。

https抓包

tcp/ip三次握手

19 客户端向443端口发送SYN信号

21 服务端回应连接

22 tcp/ip三次握手完成

ssl层

25 Client Hello信号,客户端发送随机数字+自己可以支持的加密方法。

26 ACK应答

25 Server Hello信号,服务器发送随机数字+选择双方都支持的加密方式,这里选择的是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,后面还将自己的证书发送了。

26 发送自己的公钥和从CA申请的证书

公钥和证书

27 服务端发送DH算法的参数,并发送Server Hello Done信号,发送Sever key change,告诉客户端我开始转换成对称秘钥了

28 TCP/IP的ACK接收信号

29 在这期间,客户端验证CA的证书,并且在第一步交换DH算法的参数,此时客户端和服务端的对称算法秘钥达成一致。在第二步中,客户端发送Change cipher信号(我也开始转换成对称秘钥了),最后一步发送用对称加密的第一个数据,也就是finish信号

29号包

30 客户端发送的请求头(数据时经过加密过的)

31 new session ticket,这样的操作是为了之后不用再进行握手,节约服务器的资源

32 服务端用密文形式发送的html文档

80 encrypt alert,通信结束信号

78、79、81、82 tcp/ip的断开连接

重新连接https

在经过上一次的握手之后,下一次的https的重连接会变得更加简洁
https重连接

在49号数据包上的Client hello上,附加了上次服务器给的new session ticket,这样就减少了验证的次数,使重新连接更加方便

重连接的sessionid

一些问题的解答

CA发行的证书可以证明域名是服务器端所有,但是谁又能证明证书是可靠的而不是伪造的呢?

在https通信中,证书就是数字签名,浏览器可以通过公钥对数字签名进行解密来证实服务器公钥的有效性。而数字签名的公钥必须是最安全可靠的,其实CA厂商的公钥都是保存在操作系统中的,这样就保证了公钥一定是最安全的。以前还发生过一些CA公司私钥泄露的事情,以至于全球的操作系统必须马上更新。

参考链接

RSA公钥,私钥和数字签名这样最好理解

HTTPS和证书

【腾讯TMQ】从 wireshark 抓包开始学习 https