# HTTPS

## 概述

HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

#### TLS

刚开始听到`TLS`的时候，你可能还不太熟悉，但是说起`SSL`你可能就觉得好耳熟了。其实`TLS`就是从`SSL`发展而来的，只是`SSL`发展到3.0版本后改成了`TLS`。

## 工作原理

![](/files/-LwXLoq7aPOI4Rmx645a)

![](/files/-LwbNYBVI-fxQQPgqGa3)

**1、客户端发起HTTPS请求**

用户在浏览器里输入一个https网址，然后连接到server的443端口。

**2、服务端的配置**

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。

这套证书其实就是一对公钥和私钥，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

**3、传送证书**

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

**4、客户端解析证书**

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。

如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

第3\~第4步

![](/files/-M0rll2Ku7awPivB0-vc)

**5、传送加密信息**

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

**6、服务段解密信息**

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

**7、传输加密后的信息**

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

**8、客户端解密信息**

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。

## 深度

### 对称加密与非对称加密

`对称加密`是最简单的方式，指的是`加密`和`解密`用的是**同样的密钥**。

`非对称加密`，如果有 A、 B 两把密钥，如果用 A 加密过的数据包只能用 B 解密，反之，如果用 B 加密过的数据包只能用 A 解密。

### 过程（对称+非对称）

1. 浏览器会给服务器发送一个随机数`client_random`和一个加密的方法列表。
2. 服务器接收后给浏览器返回另一个随机数`server_random`和加密方法
3. **浏览器接收，接着生成另一个随机数`pre_random`, 并且用公钥加密，传给服务器。(敲黑板！重点操作！)**
4. **服务器用私钥解密这个被加密后的`pre_random`**

{% hint style="info" %}
第3到第4是非对称加密
{% endhint %}

现在浏览器和服务器有三样相同的凭证:`client_random`、`server_random`和`pre_random`。然后两者用相同的加密方法混合这三个随机数，生成最终的`密钥`

然后浏览器和服务器尽管用一样的密钥进行通信，即使用`对称加密`。

{% hint style="info" %}
日常通信是对称加密
{% endhint %}

这个最终的密钥是很难被中间人拿到的，为什么呢? 因为对称加密的密钥是建立在非对称加密上的，非对称加密没有私钥是无法解开的。

为什么单纯使用非对称加密？因为非对称加密的性能比较低。

回头比较一下和单纯的使用**非对称加密**, 这种方式做了什么改进呢？本质上是**防止了私钥加密的数据外传**。单独使用**非对称加密**，最大的漏洞在于服务器传数据给浏览器只能用`私钥`加密，这是危险产生的根源。利用`对称和非对称`加密结合的方式，就防止了这一点，从而保证了安全。

### 中间人攻击

中间人攻击过程 

1. 客户端发送请求到服务端，请求被中间人截获
2. 服务器向客户端发送公钥
3. 中间人截获公钥，保留在自己手上。然后自己生成一个【伪 造的】公钥，发给客户端。
4. 客户端收到伪造的公钥后，生成加密hash值发给服务器
5. 中间人获得加密hash值，用自己的私钥解密获得真秘钥。同时生成假的加密hash值，发给服务器。
6. 服务器用私钥解密获得假密钥。然后加密数据传输给客户端。

### 为什么需要数字证书

尽管通过两者加密方式的结合，能够很好地实现加密传输，但实际上还是存在一些问题。**黑客如果采用 DNS 劫持，将目标地址替换成黑客服务器的地址，然后黑客自己造一份公钥和私钥，照样能进行数据传输。**而对于浏览器用户而言，他是不知道自己正在访问一个危险的服务器的。

### 数字证书怎么是可信的？

首先应用程序读取证书中的Issuer（发布机构），然后会在操作系统或浏览器内置的受信任的发布机构中去找该机构的证书（为什么操作系统会有受信任机构的证书？先看完这个流程再来回答）。如果找不到就说明证书是水货，证书有问题，程序给错误信息。如果找到了，或用户确认使用该证书。就会拿上级证书的公钥，解密本级证书，得到数字指纹。然后对本级证书的公钥进行数字摘要算法（证书中提供的指纹加密算法）计算结果，与解密得到的指纹对比。如果一样，说明证书没有被修改过。

接下来解答操作系统为什么会有证书发布机构的证书？

其实证书发布机构除了给别人发布证书外，自己也有自己的证书。在操作系统安装好时，受信任的证书发布机构的数字证书就已经被微软安装在操作系统中了。

> <https://zhuanlan.zhihu.com/p/60033345>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://mm.ricky.moe/network/ji-suan-ji-wang-luo/https.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.