【Network】加密方式

对称加密

① 客户端生成密钥、② 客户端将密钥发送给服务端、③ 请求：客户端使用密钥加密数据并请求服务端，服务端使用密钥解密数据并处理；响应：服务端使用密钥加密数据并响应，客户端使用密钥解密数据并处理

对称加密的问题：在 ② 中，可能会被中间人拦截并获取密钥，即可直接窃取、篡改数据。

非对称加密

① 服务端生成公钥和私钥、② 服务端将公钥发送给客户端、③ 请求：客户端使用公钥加密数据并请求服务端，服务端使用私钥解密数据并处理；响应：服务端使用私钥加密数据并响应，客户端使用公钥解密数据并处理

非对称加密的问题：在 ② 中，可能会被中间人拦截并获取公钥，然后用自己的公钥替换掉合法的公钥。客户端发起请求时，就会使用攻击者的公钥加密数据，攻击者拦截请求并用自己的私钥解密数据，即可窃取、篡改数据。为了解决这个问题，可以使用数字证书来验证公钥的合法性。

数字证书

① 服务端生成公钥和私钥、② 服务端把公钥等信息发送给证书颁发机构（CA）、③ CA 用自己的私钥对这些信息进行加密 (加密后的内容就是证书)、④ CA 将证书以较安全的方式 (比如电子邮件) 发送给服务端，并将自己的公钥以较安全的方式发送给客户端 (CA 机构公钥通常是浏览器/操作系统内置的)、⑤ 服务端将证书发送给客户端、⑥ 客户端用 CA 的公钥解密证书，验证证书的合法性并提取服务端的公钥、⑦ 请求：客户端使用服务端的公钥加密数据并请求服务端，服务端使用私钥解密数据并处理；响应：服务端使用私钥加密数据并响应，客户端使用公钥解密数据并处理

混合加密

非对称加密相比对称加密在处理大量数据时效率较低。通常情况下，非对称加密用于安全地交换对称加密的密钥，然后使用对称加密来加密实际的消息内容。这个对称加密的密钥被称为会话密钥，它是随机生成的，用于本次通信。

① 服务端生成公钥和私钥、② 服务端把公钥等信息发送给证书颁发机构（CA）、③ CA 用自己的私钥对这些信息进行加密 (加密后的内容就是证书)、④ CA 将证书以较安全的方式 (比如电子邮件) 发送给服务端，并将自己的公钥以较安全的方式发送给客户端 (CA 机构公钥通常是浏览器/操作系统内置的)、⑤ 服务端将证书发送给客户端、⑥ 客户端用 CA 的公钥解密证书，验证证书的合法性并提取服务端的公钥、⑦ 客户端生成会话密钥，用服务端的公钥加密会话密钥并发送给服务端、⑧ 服务端用私钥解密会话密钥、⑨ 请求：客户端使用会话密钥加密数据并请求服务端，服务端使用会话密钥解密数据并处理；响应：服务端使用会话密钥加密数据并响应，客户端使用会话密钥解密数据并处理

混合加密的问题：只要中间人能够获取私钥，就能为所欲为。中间人可以拦截请求和响应并存储下来，耐心等待服务端的私钥泄露。只要服务端的私钥泄露，中间人就能解密存储下来的所有请求和响应信息。也就是不具备 “前向保密性” (forward secrecy)。

解决办法就是每次建立安全连接都使用动态的私钥，但是这样做非常耗费资源。于是动态私钥的 “DH 系” 密钥交换方式 (如 ECDHE) 应运而生。

DH 密钥交换 (Diffie-Hellman Key Exchange)

① 客户端取两杯数量一样的红豆和一杯定量的黑豆，服务端取两杯数量一样的绿豆和一杯定量的黑豆，这里客户端和服务端的黑豆是一样的、② 客户端把一杯红豆和黑豆混合，服务端把一杯绿豆和黑豆混合、③ 双方交换混合物、④ 收到混合物后，双方把自己的豆子都混合在一起。到此，双方都得到了一摸一样的材料，用这个材料就可以生成相同的密钥。

在 ③ 中，中间人可以拦截混合物，但由于中间人不知道客户端的红豆和服务端的绿豆各有多少，所以得不到相同的材料。

通常客户端和服务端会交换一个随机数，然后用这两个随机数合并到 ④ 中的混合物中，再以此生成密钥。这个密钥称为 “主密钥”。

DH 密钥交换的问题：中间人拦截到请求/响应后，虽然无法解密，但可以原封不动地返回给双方，就会造成客户端服务端的事务紊乱。

解决办法就是客户端和服务端再交换一个随机数，将这两个随机数合并到主密钥中，派生出客户端密钥和服务端密钥。客户端请求数据时，用客户端密钥加密数据，服务端用客户端密钥解密数据；服务端响应数据时，用服务端密钥加密数据，客户端用服务端密钥解密数据。

实际使用中，除了客户端密钥和服务端密钥，还会派生 MAC KEY 用于验证数据、IV 用于加密初始化向量等。这就是 tls 1.2 的完整加密流程。

可见 tls 1.2 的加密流程十分繁琐，tls 1.3 为了简化流程，把所有要传递的加密材料、随机数等合并发送，使得 tls 1.3 中只需要一个来回就完成了通信建立。

http + tls = https