https探究

最新推荐文章于 2024-02-25 22:17:42 发布

zpsimon

最新推荐文章于 2024-02-25 22:17:42 发布

阅读量336

点赞数

分类专栏：运维大桶文章标签： https 安全

本文链接：https://blog.csdn.net/zpsimon/article/details/114883337

版权

运维大桶专栏收录该内容

20 篇文章 0 订阅

订阅专栏

1.4 使用wireshark抓包分析https访问过程

二. 如何使用wireshark解密https流量？

三. https相对于http的优缺点？

参考文章：

https越来越常见，对于数据安全也是至关重要的。但对其原理之前有点模糊，特意整理一下，以防备忘。

一.什么是https以及其原理是什么？

1.1https是什么？

HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），即‘超文本安全传输协议’。是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 ] 。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。它被广泛用于万维网上安全敏感的通讯，例如交易支付等方面 [2] 。

1.2 https原理

HTTPS 主要由两部分组成：HTTP 协议+ SSL协议 / TLS协议，也就是在 HTTP 上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过 TLS 进行加密，所以传输的数据都是加密后的数据。

通常，HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信了。简言之，所谓HTTPS，其实就是身披SSL协议这层外壳的HTTP

HTTPS 协议的“安全”主要依赖于 TLS/SSL 协议，TLS/SSL 的功能实现主要依赖于三类基本算法：

非对称加密：客户端与服务单是多对1的关系，多个客户端共用一套公钥（FPP），只有服务端拥有私钥(FPK)，所以客户端信息只能由服务端通过私钥来解密获取。 --主要用于身份验证和秘钥协商。

"秘钥协商”：客户端用非对称加密算法对外公开的公钥加密（假设为FPP）用户数据传输的对称秘钥（DK），传输至服务端，服务端用非对称加密的私钥（假设FPK）解密出对称秘钥（DK）。这样就完成对称秘钥的安全传输。

对称加密：客户端和服务端共享相同秘钥，但不同客户端秘钥不同。 --主要用于对数据进行加密
散列函数：函数不可逆，对输入敏感，输出长度固定。 --主要用于数据完整性校验

“数字签名”：服务端对要发送的数据先使用hash()函数生成一个摘要（digest1），然后使用服务端的私钥（FPK）对这个摘要进行加密就生成了一个“数字签名（signature）”。客户端收到带有数字签名的数据后，用公钥对数字签名进行解密得到一个摘要digest2。客户端比较digest1 和digest2如果相同，则表明此份带有数字签名的数据确实是服务端发布的。如下图所示：

但这样有一种风险就是，服务端的公钥FPP可能会在公布时被中间人恶意替换。比如client1-->server1 这种交互场景中。如果server1发布的公钥被server2（比如是恶意网站）替换。此时client1拥有的就是server2的公钥，就会出现client1认为server2是要访问的网站，而server1反倒被认为是恶意网站。这是就需要一种机制来保证client1访问server1时获取的公钥是值得信任的。这就需要引入一种“数字证书”的东西。

“数字证书”：服务端（server1）为证明自己的公钥确实属于自己的某个机构（或个人），就找公信力被客户端和服务端都认同的认证机构（certificate authority，即CA）为自己的公钥以及其他信息进行权威认证。服务端找CA认证时需要提供如营业执照,身份证,授权委托书，公钥等信息，CA机构用自己的私钥，对server1的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。后续server1传输数据给client1时，附带数字签名和数字证书。client1收到数据后用CA的公钥（CA公钥的正确性检查一般在浏览器都有集成一些权威CA或者CA的子机构的证书）解密得到server1的公钥。

1.3 https类型的网页访问流程

1.4 使用wireshark抓包分析https访问过程

如下是我使用https GET一个测试页面的数据包截图

简述过程：

①三次握手建立tcp连接；

②ssl/tls层协议握手（身份认证、session key的交换）； --相比http请求多了这个步骤

③正式http请求交互；

④四次挥手断开连接

分析如下：

1）1,3,4号包是tcp三次握手建立连接，由此可见https协议也是基于http协议的；

2）5,9,10,11,17,19,20号包是TLS层握手、证书验证、会话秘钥生成等动作。5号包客户端告知服务端TLS协议握手的一些信息,如：TLS版本、Cipher Suites表示客户端支持的加密算法组合，每一个组合包含“非对称加密算法+堆成机密算法+hash算法”；

3）9号包时5号包的ACK，server端返回TLS协议握手相关信息

4）10号包是server返回的https证书

5）11号包是client发送针对10号包的ACK，表示client已经收到证书

6） 17号包，client端发送client key

7）19号包，server生成会话秘钥

8） 20号包，client收到会话秘钥

9）23号包client正式发起http请求；24号包server回复收到请求；25号返回响应数据（这里之所以能看到明文数据，是因为在wireshark上配置了证书，参考下文如何解密https数据包）

10）26号包，server通知要断开连接；

11）27,28,29,30 号包正式断开tcp连接。

二. 如何使用wireshark解密https流量？

使用wireshark有2种方式解密https数据，如下：

Key log file using per-session secrets (#Using_the_.28Pre.29-Master-Secret). （推荐）
Decryption using an RSA private key.

两种方式都有适应的场景，A key log file这种使用所有场景。而RSA private key 这种方式只适应有限的几种场景。

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.