今天有点空闲时间看了一下网上的一些关于https的文章,发现一个问题,很多文章都大谈特谈https的混合加密过程,但我没看到一篇文章谈到更具体的使用什么对称加密算法和非对称加密算法,于是有了这篇我自己体验的更详细的文章。
首先要安装wireshake,安装过程不表。安装好wireshark直接打开,选择对的网络接口,打开百度网址,然后就可以看到很多的报文汹涌而来。这里建议使用过滤器把不必要的报文过滤掉,省得看着心烦。下面是我的过滤条件:
ssl && ip.addr==163.177.151.110
后面的地址是我抓取到的百度的ip地址。效果如下图所示:

这里可以清晰的看出https协议的握手过程。
首先,是浏览器向服务器发送Client Hello报文.
看看这个报文里有什么重要的东西,首先是浏览器支持的密码工具套件(cipher suites)

这里可以看出确实有很多的方案。下面还有浏览器支持的椭圆曲线

接着是服务器返回的Server Hello


可以看到,这里服务器已经返回一个选好的加密工具套件了,以后双方就用这个套件进行操作。
接着服务端向浏览器发送证书

可以看到这里发了两张证书,我不知道为什么要发两张证书。
接着服务端向浏览器发送Server Key Exchange消息

服务器再向浏览器发送Server Hello Done消息,表明握手协议结束

浏览器一次性向服务端发送多个handshake消息

后来服务端向浏览器发送Change Cipher Spec消息和两个Hello Request消息。


总的感觉就是顺序有点乱。那到底怎样的顺序才是正确的HTTPS握手顺序呢?
下面是我在服务器上用curl测试百度的结果:
curl -v https:///www.baidu.com
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
大概也是这个过程,但好像还是有点不同,突然觉得有点困了,就暂时到这里。
(待续)
本文通过Wireshark抓包工具深入解析HTTPS的握手过程,详细展示了客户端与服务器间交互的报文,包括ClientHello、ServerHello、证书交换及密钥协商等关键步骤。并通过curl命令验证了HTTPS握手的正确流程。
1403

被折叠的 条评论
为什么被折叠?



