mirror of
https://github.com/NohamR/knowledge-kit.git
synced 2026-05-25 12:27:15 +00:00
85 lines
5.2 KiB
Markdown
85 lines
5.2 KiB
Markdown
# Charles 抓包原理
|
||
|
||
> HTTPS(Hyper Text Transfer Protocol Secure)，是一种基于SSL/TLS的HTTP，所有的HTTP数据都是在SSL/TLS协议封装之上进行传输的。HTTPS协议是在HTTP协议的基础上，添加了SSL/TLS握手以及数据加密传输，也属于应用层协议。所以，研究HTTPS协议原理，最终就是研究SSL/TLS协议。
|
||
|
||
|
||
|
||
|
||
|
||
### 运行过程
|
||
|
||
我们都知道HTTPS在保证数据安全传输上使用了加密算法，但是具体是如何加密的，或许许多人和我一样也是云里雾里。
|
||
实际上SSL/TLS协议的基本思路是非对称加密和对称加密结合来传输数据，**一言以弊之，HTTPS是通过一次非对称加密算法（如RSA算法）进行了协商密钥的生成与交换，然后在后续通信过程中就使用协商密钥进行对称加密通信**，之所以要使用这两种加密方式的原因在于非对称加密计算量较大，如果一直使用非对称加密来传输数据的话，会影响效率。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
#### 1. HTTPS请求
|
||
|
||
这个步骤是整个通信过程中的第一步，首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，在这一步中，客户端主要向服务器提供以下信息：
|
||
|
||
- 支持的协议版本，比如TLS 1.0版
|
||
- 一个客户端生成的随机数RandomC，稍后用于生成**“协商密钥”**。
|
||
- 支持的加密方法，比如RSA公钥加密。
|
||
- 支持的压缩方法。
|
||
|
||
#### 2. 服务器响应
|
||
|
||
服务器收到客户端请求后，向客户端发出回应，服务器的回应一般包含以下内容：
|
||
|
||
- 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
|
||
- 一个服务器生成的随机数RandomS，稍后用于生成*“协商密钥”**。
|
||
- 从客户端支持的加密方法中选择一个作为确认要使用的加密方法，比如RSA公钥加密。
|
||
- 服务器证书。
|
||
这个服务器证书就是表明服务器身份的东西，其中也包含了非对称加密中需要使用的公钥。
|
||
|
||
#### 3. 证书校验、生成密码、公钥加密
|
||
|
||
客户端收到服务器回应以后，首先验证服务器返回的证书。如果证书不是可信机构颁发，或者证书中的域名与实际域名不一致，或者证书已经过期，以浏览器为例客户端会向网页访问者显示一个警告，由其选择是否还要继续通信。 如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后生成密码、公钥加密。
|
||
生成密码的过程会先产生一个随机数Pre-master key，该随机数是整个握手阶段出现的第三个随机数，稍后会经过公钥加密发送到服务端，有了它以后，客户端和服务器就同时有了三个随机数——RandomC，RandomS，Pre-master key，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把“协商密钥”。
|
||
|
||
#### 4. 加密信息C-S
|
||
|
||
加密信息是指上面一步生成的内容，主要包括
|
||
|
||
- 一个随机数Pre-master key。用于给服务端生成“协商密钥”。
|
||
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
|
||
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项通常也是前面发送的所有内容的hash值，用来供服务器校验。
|
||
|
||
#### 5. 私钥解密、解密握手消息、验证Hash
|
||
|
||
服务器收到客户端公钥加密的第三个随机数Pre-master key之后，通过自身私钥解密该数值并由之前的RandomC和RandomS计算生成本次会话所用的“会话密钥”。然后，通过约定的Hash算法验证客户端发送的数据完整性。
|
||
|
||
#### 6. 加密信息S-C
|
||
|
||
主要是指
|
||
|
||
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
|
||
- 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发生的所有内容的hash值，用来供客户端校验。
|
||
|
||
#### 7. 解密握手消息、验证Hash
|
||
|
||
客户端解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束。
|
||
|
||
#### 8. 正常加密通信
|
||
|
||
握手成功之后，所有的通信数据将由之前协商密钥及约定好的算法进行加密解密。
|
||
|
||
# Charles抓HTTPS包原理
|
||
|
||
Charles本身是一个协议代理工具，如果只是普通的HTTP请求，因为数据本身没经过再次加密，因此作为代理可以知道所有客户端发送到服务端的请求内容以及服务端返回给客户端的数据内容，这也就是抓包工具能够将数据传输内容直接展现出来的原因。对于HTTPS请求，4，6，8步骤的数据都已经经过了加密，代理如果什么都不做的话是无法获取到其中的内容的。为了实现这个过程的数据获取，Charles需要做的事情是对客户端伪装服务端，对服务端伪装客户端，具体
|
||
|
||
- 截获真实客户端的HTTPS请求，伪装客户端向真实服务端发送HTTPS请求
|
||
- 接受真实服务器响应，用Charles自己的证书伪装服务端向真实客户端发送数据内容
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|