> For the complete documentation index, see [llms.txt](https://book.gxd88.cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.gxd88.cn/what-happens-when/https-communication.md).

# Https 的通信过程?

## 01.TLS证书的通信过程

### 0101.非对称加密的过程

比较主流的非对称加密算法为RSA， 什么事非对称加密算法呢？\
简单的来说加密过程使用对方的公钥进行加密， 解密的时候使用自己， 如下图所示：

```
+---+     +------+  加密后的数据传输给B    +------+       +---+
| A | --> |  加密 | ------------------>  |  解密 | --> | B |
+---+     +------+                      +------+       +---+
            ^                              ^
            |                              |
            |                              |
          +--------+                    +--------+
          | B的公钥 |                    | B的私钥 |
          +--------+                    +--------+
```

### 0102.对称加密

```
+--------------+  密钥加密   +---------+  密钥解密    +----------+
| 加密前原始文档 | ---------> | 加密文档 | ----------> | 解密后文档 |
+--------------+     A      +---------+      B       +-----------+
```

如上图所示A要给B发送文档的主要流程如下：

* A使用密钥对文档进行加密发送给B
* B使用和A加密文档的同一把密钥对文档进行解密

## 02.CA

CA我们都知道是证书签发权威机构， 那为什么会需要这样的机构呢？正常访问https的站点时CA证书又时怎么工作的呢？

为了在确保在通信的过程中通信双发的数据不被第三方劫持， 需要加入受信任的第三方来保证通信的安全，

CA证书的内容包含：电子签证机关的信息、公钥用户信息、公钥、签名和有效期。这里的公钥服务端的公钥，这里的签名是指：用hash散列函数计算公开的明文信息的信息摘要，然后采用CA的私钥对信息摘要进行加密，加密完的密文就是签名。 即：证书 = 公钥 + 签名 +申请者和颁发者的信息。 客户端中因为在操作系统中就预置了CA的公钥，所以支持解密签名（因为签名使用CA的私钥加密的）

* 证书的签发过程： 

```
       +----------------+
       v                |
+----------+  CSR    +----------+  CSR   +----+
| 证书申请人 | ----->  | 登记机构  | -----> | CA |
+----------+         +----------+        +----+
                           ^               |
                           +---------------+
```

如上图所示主要流程如下：

* 先去登记机构进行身份登记，我是谁，我是干嘛的，我想做什么，
* 然后登记机构再通过CSR发给CA，
* CA收到请求后对公钥进行数字签名，公钥会在CA证书链中保存
* CA中心将公钥和私钥证书下发给申请者

## 03.单向验证

Client仅对Server的证书进行单向验证，这种方式称为Server Authentication

![](https://1785474312-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lvt5boAx3hwVzQ2DCNd%2Fsync%2Ff761337f6edf0addceac8e6d5c1702fba8ff30f8.jpg?generation=1588906541521884\&alt=media)

详细流程如下： 1. 客户端发起HTTPS请求，将SSL协议版本的信息发送给服务端。 2. 服务端去CA机构申请来一份CA证书，在前面提过，证书里面有服务端公钥和签名。将CA证书发送给客户端 3. 客户端读取CA证书的明文信息，采用相同的hash散列函数计算得到信息摘要（hash目的：验证防止内容被修改），然后用操作系统带的CA的公钥去解密签名（因为签名是用CA的私钥加密的），对比证书中的信息摘要。如果一致，则证明证书是可信的，然后取出了服务端公钥 4. 客户端生成一个随机数（密钥F），用刚才等到的服务端B*公钥去加密这个随机数形成密文，发送给服务端。 5. 服务端用自己的B*私钥去解密这个密文，得到了密钥F 6. 服务端和客户端在后续通讯过程中就使用这个密钥F进行通信了。和之前的非对称加密不同，

如上图的第3步浏览器会对证书进行如下几方面的验证

* 检查SSL 证书是否是由浏览器中“受信任的根证书颁发机构”颁发
* 检查SSL证书中的证书吊销列表，检查证书是否被证书颁发机构吊销
* 检查此SSL证书是否过期
* 检查部署此SSL证书的网站的域名是否与证书中的域名一致

## 04.双向认证

在进行单项认证的基础上可能还存在Server对Client的验证， 这种方式称为Client Authentication， 将Client到Server的验证和Server到Client的验证结合起来就是双向认证

![](https://1785474312-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-Lvt5boAx3hwVzQ2DCNd%2Fsync%2F23690bac80ddbf5c8bbaeefd06bd4e39ce9329dd.jpg?generation=1588906540509011\&alt=media)

详细过程如下： 图中步骤1-3就是上文中谈到的Server Auth，而步骤4-5就是Client Auth，两者的认证都需要借助CA认证机构（当然并不一定是同一家CA认证机构）进行校验，因此这种认证称为"双向认证"

## 03.参考

[Kubernetes数字证书体系浅析](https://www.secrss.com/articles/13238)