欢迎您光临深圳塔灯网络科技有限公司!
电话图标 余先生:13699882642

网站百科

为您解码网站建设的点点滴滴

通过抓包分析HTTPS

发表日期:2018-07 文章编辑:小灯 浏览次数:1957

//第一步,为服务器端和客户端准备公钥、私钥 # 生成服务器端私钥 openssl genrsa -out server.key 1024 # 生成服务器端公钥 openssl rsa -in server.key -pubout -out server.pem//第二步,生成 CA 证书 # 生成 CA 私钥 openssl genrsa -out ca.key 1024 # X.509 Certificate Signing Request (CSR) Management.ca证书签名请求 #要求填写一些资料。Common Name是能访问的域名 openssl req -new -key ca.key -out ca.csr# X.509 Certificate Data Management.生成ca证书 openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt//第三步,生成服务器端证书 # 服务器端需要向 CA 机构申请签名证书,在申请签名证书之前依然是创建自己的 CSR 文件 openssl req -new -key server.key -out server.csr # 向自己的 CA 机构申请证书,签名过程需要 CA 的证书和私钥参与,最终颁发一个带有 CA 签名的证书 openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.cr 

之后再配置nginx的ssl即可

接下来通过WireShark抓包分析https协议的交互过程

  1. 客户端首先向服务器端发送一个 Client Hello 的 SSL 握手信息。
image.png

虽然只有 Client Hello 两个单词,但是其消息体里面包含了丰富的信息,我们在 WireShark 上选择这行记录,并双击,其里面包含了下面的一些主要信息。

enter image description here

(1)Handshake Type:Client Hello(握手类型)。

(2)Random(随机数)和一个时间戳。

enter image description here

(3)客户端支持的加密协议套装。

enter image description here

告诉 HTTPS 的服务器端,客户端能支持上面这 26 种加密协议套装上列出的算法,让服务器选择一个加密协议算法套装。

(4)访问的 Web 服务器的信息:

enter image description here

(5)客户端支持的签名算法:

enter image description here

客户端告诉服务器其支持 9 种签名算法,让服务器端自由选择一个用于后续的加密通信。

2. HTTPS 服务器马上给客户端回复 4 条 SSL 握手信息

enter image description here

HTTPS 服务器马上给客户端回复了下面这 4 条 SSL 握手信息。

  • Server Hello
  • Certificate
  • Server Key Exchange Server
  • Hello Done

下面具体来看这 4 条由 HTTPS 服务器端发出的 4 条消息里面到底有什么内容,其会告诉客户端什么秘密和信息呢?

(1)Server Hello SSL 握手信息

enter image description here

其重点是把客户端发送给服务器端的随机数又给发送回去了,而且还生成了服务器端的 Session ID 并发送给客户端,最后告诉客户端,服务器端准备选择TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384作为秘钥交互的加密协议套装,该加密协议的套装名字肯定出现在客户端发送给服务器的支持的 26 个列表中,不信你可以翻回去对比一下。

(2)Certificate

enter image description here

SSL 服务器证书信息。在这条 HTTPS 服务器给客户端回复消息 SSL 握手信息里面,其还会把服务器端的 SSL 证书发送给客户端,从上图的转包信息中,我们能清晰地发现服务器端 SSL 证书的相关信息,比如,通用名字为 iis-web-01,组织单元为 it 等。

需要注意的是,如果是 SSL 的双向认证,服务器端也可以要求客户端把 SSL 证书发送给服务器端(对应的 SSL 握手消息名称为:CertificateRequest),这个时候,客户端就会把其 SSL 证书发送给服务器端,从而证明其就是服务器端信任的客户端。

(3)Server Key Exchange 握手消息

enter image description here

HTTPS 服务器出大招了,告诉了客户端其将会采用的 EC Diffie-Hellman 算法进行 HTTPS 服务器和客户端的秘钥交换。具体什么是 EC Diffie-Hellman 算法,大家可以自行查阅资料,这里不再赘述,并提供了 EC Diffie-Hellman 算法使用到的服务器端的参数:

  • 曲线类型:named_curve: secp256r1
  • 公钥信息
  • 签名的算法:rsa_pkcs1_sha1
  • 签名的信息

(4)Server Hello Done 握手信息

握手信息列表结束了。

enter image description here

3. HTTPS 客户端马上给服务器端回复 3 条 SSL 握手信息

当客户端收到服务器端的相关公钥信息,SSL 证书以及摘要算法和摘要信息后,也不是无动于衷,而是积极的响应了下面的 3 条 SSL 握手信息。

enter image description here
  • Client Key Exchange
  • Change Cipher Spec
  • Encrypted Handshake Message

那么这三条 SSL 的握手信息将会透露出什么?客户端到底想告诉服务器端什么?让我们一一分解。

(1)Client Key Exchange 握手信息

enter image description here

其给服务器端发送了一条用服务器端公钥加密的信息,其里面就包含了预备主密码(Pre-Master secret),其是由客户端随机生成,之后会被用作生成主密码的种子。根据预备密码,服务器和客户端会计算出相同的主密码(Master secret),然后根据主密码生成下面的比特序列(秘钥素材)。

  • 对称密码的秘钥
  • 消息认证码的秘钥
  • 对称密码的 CBC 模式中使用的初始化向量(IV)

需要注意的是,Client 秘钥交换的方式主要有两种,一种是通过 RSA 公钥密码进行交互,这个时候客户端会在发送 ClientKeyExchange 消息时,将经过加密的预备主密码一起发送给服务器。当使用 Diffie-Hellman 交换秘钥的时候,客户端会在发送 ClientKeyExchange 消息时,将 Diffie-Hellman 公开值(Pub Key)一起发送给服务器,根据这个值,客户端和服务器会各自生成预备主密码,而且更加这个预备主密码能够生成相同的对称主密码。

(2)Change Cipher Spec 握手信息

enter image description here

告诉服务器端,我要切换密码了!

(3)Encrypted Handshake Message 握手信息

enter image description here

客户端发出使用主密码加密的结束信息,告诉服务器端:“秘钥交换握手协议到此结束”。

4. HTTPS 服务端马上给客户端回复 2 条 SSL 握手信息

enter image description here

这次轮到服务器端发送“Change Cipher Spec”消息了,服务器告诉客户端:“好,现在我也要切换密码了”。

服务器端用预备主密码(Pre-Master secret)计算出的主秘钥加密了一条信息,并发送给客户端:“好的,秘钥交换握手协议到此结束”。如果通信双方都能把结束消息解密成功,说明主秘钥已经交换成功。就可以发送真正的用主密码加密的应用数据的信息了!

5. 服务端用对称秘钥把加密过的 HTML 网页内容发送给客户端

enter image description here

服务器端用成功交换了秘钥把加密过的 HTML 网页内容发送给客户端,客户端用以前收到过的对称秘钥进行解密,HTTPS 通信协议圆满结束。

上面的步骤只是把我当前环境下抓取到的使用 TL S1.2 协议规范进行了 HTTPS 通信原理和过程的梳理和解释,在不同的环境下,其通信过程会有一些差异,比如,如果配置了双向 SSL 认证,其 SSL 服务器端还会要求客户端把客户端的证书发送到服务端,从而验证客户端是否是可信任的,另外在进行主密码交换的过程中,也可能采用 RSA 公钥密码,而不是 Diffie-Hellman,此时,其 SSL 握手消息会有所不同,但是整体的流程和交互过程思路基本上保持相同。

上述具体流程如下图所示


7042f5c3d9e3437d5b0b30b30f43c802.jpg
本页内容由塔灯网络科技有限公司通过网络收集编辑所得,所有资料仅供用户学习参考,本站不拥有所有权,如您认为本网页中由涉嫌抄袭的内容,请及时与我们联系,并提供相关证据,工作人员会在5工作日内联系您,一经查实,本站立刻删除侵权内容。本文链接:https://dengtar.com/20428.html
相关开发语言
 八年  行业经验

多一份参考,总有益处

联系深圳网站公司塔灯网络,免费获得网站建设方案及报价

咨询相关问题或预约面谈,可以通过以下方式与我们联系

业务热线:余经理:13699882642

Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.    

  • QQ咨询
  • 在线咨询
  • 官方微信
  • 联系电话
    座机0755-29185426
    手机13699882642
  • 预约上门
  • 返回顶部