了解https原理，对称加密/非对称加密原理，浏览器与服务器加密的进化过程，https做了些什么
最开始的加密
浏览器与服务器之间需要防止传输的数据被黑客破解。因此，浏览器在发送数据时会对数据进行加密，并把加密的密钥（或密钥的某些部分）放在数据的某一个区域中。服务器收到数据后，会提取密钥并用它来解密数据。这样的加密方式称为 对称加密。
对称加密的缺点
问题在于，当多个客户端都使用相同的加密算法时，黑客可以通过拦截和分析加密数据，推测出加密密钥的位置。这个过程叫做密钥泄漏，因此，对称加密 在密钥管理上有较大风险，一旦密钥被泄漏，通信的安全性就会受到威胁。因此，传统的对称加密不完全安全。
非对称加密
后来，科学家们发现了 非对称加密 的方法，这种方法解决了对称加密中的密钥管理问题。
非对称加密原理
非对称加密的基本思想是：使用公钥加密，使用私钥解密。其中，公钥可以公开，任何人都可以用它来加密消息，而私钥只有对应的接收方才能拥有，只有拥有私钥的人才能解密消息。
加密过程如下：
- 服务器拥有一对 公钥 和 私钥，其中 公钥 是公开的，任何人都可以获取，而 私钥 则严格保密。
- 客户端想要与服务器进行通信时，会使用 服务器的公钥 来加密消息。
- 服务器收到消息后，用自己的 私钥 解密消息。
通过这种方式，只有服务器能够解密客户端发送的消息，确保了数据的机密性。
非对称加密的缺点
- 这种方法存在一个问题，即 服务器到客户端 的消息并没有加密，黑客依然可以拦截服务器发送的消息，因为它们是明文的。
双向非对称加密
为了更好地保护通信的双方，提出了 双向非对称加密。在这种加密模式中，双方都有公钥和私钥，并通过交换公钥进行加密和解密。
双向非对称加密流程：
- 客户端和服务器都各自拥有一对公钥和私钥。
- 客户端向服务器发送请求时，会先发送自己的公钥给服务器。
- 服务器收到客户端的公钥后，也发送自己的公钥给客户端。
- 然后，客户端和服务器互相使用对方的公钥加密消息，自己用私钥解密对方的消息。
双向非对称加密的缺点
- 计算资源消耗大：非对称加密算法（如 RSA）相较于对称加密（如 AES）来说，计算资源消耗较大，可能会导致网页渲染变慢，影响用户体验。
非对称加密 + 对称加密的结合
为了解决双向非对称加密中的性能问题，现代网络通信通常结合了 非对称加密 和 对称加密。
加密流程：
- 第一次请求：客户端在与服务器建立连接时，使用 服务器的公钥 加密一个随机生成的 对称密钥（例如 AES 密钥）。
- 服务器使用 自己的私钥 解密该对称密钥。
- 一旦密钥交换完成，客户端和服务器就可以使用这个对称密钥进行加密和解密数据，后续的数据传输都使用高效的对称加密进行保护。
这种方式既保证了通信的安全性，又避免了非对称加密带来的性能问题。
非对称加密 + 对称加密的结合 —— 升级版
在实际应用中，单纯的非对称加密和对称加密结合方式依然存在一些潜在的安全隐患，尤其是客户端生成的私钥较容易被猜测出来。为此，引入了 随机数生成 来进一步提高安全性。
升级版的加密流程：
- 客户端随机数：客户端在第一次通信时，向服务器发送一个随机数 1。
- 服务器随机数：服务器回应时，会发送一个包含随机数 2 的请求。
- 客户端生成随机数：客户端收到服务器的请求后，会生成一个随机数 3，并用 服务器的公钥 加密后发送给服务器。
- 双方密钥生成：客户端和服务器通过这三个随机数生成对称加密密钥（如 AES 密钥）。
- 双方用这个密钥进行后续的数据加密和解密。
校验密钥一致性
在密钥生成后，双方需要校验生成的对称密钥是否一致，以确保双方的随机数生成的秘钥都是正确的
非对称加密 + 对称加密的结合的漏洞 —— 中间人攻击
虽然 非对称加密 + 对称加密 的结合在理论上很安全，但仍然存在 中间人攻击 的风险。
中间人攻击示意图：
客户端 <----> 恶意服务器 <----> 目标服务器攻击流程：
- 客户端发起请求时，恶意服务器伪装成目标服务器，并向客户端发送自己的 公钥。
- 客户端误将数据用恶意服务器的 公钥 加密，并发送给恶意服务器。
- 恶意服务器用自己的 私钥 解密数据，获得客户端的私钥和密钥信息。
- 恶意服务器将数据转发给目标服务器，并伪装成客户端进行后续通信。
- 通过这种方式，恶意服务器可以窃取通信双方的敏感信息。
CA证书（HTTPS认证）
为了防止中间人攻击，SSL/TLS 引入了 CA（证书颁发机构）认证。CA机构充当了一个“公证人”的角色，帮助验证服务器的身份。
证书签发过程：
- 服务器将域名、公司信息等提交给 CA 进行认证。
- CA 使用其 私钥 对服务器信息进行加密，生成一个 数字签名。
- 将该签名与服务器信息一起打包，返回给服务器，这样就完成了认证。
证书验证过程：
当客户端与经过 CA 认证的服务器建立连接时：
- 服务器将自己的证书（包含公钥和数字签名）发送给客户端。
- 客户端计算该证书的 hash 值（称为 hash1），然后使用 CA 的公钥 解密数字签名得到 hash2。
- 如果 hash1 和 hash2 相同，则说明证书没有被篡改，通信是安全的。
- 如果证书验证失败，浏览器会警告用户连接不安全。
CA证书服务器的认识
为了避免单个 CA 证书服务器的负担过重，CA 采用了分层认证架构。根级 CA 服务器是最权威的，下面的中级 CA 服务器可以为下级的证书颁发机构提供认证服务。
CA 证书验证过程：
- 客户端验证服务器证书时，首先验证证书的签发机构。
- 如果证书由根证书服务器签发，验证成功。如果证书不是根证书，则会向上逐层验证签发证书，直到找到根证书。
- 根证书通常已经预安装在操作系统或浏览器中，一旦找到可信根证书，验证过程就完成。
图示：SSL/TLS通信过程
±------------------+ ±---------------------+
| Client | | Server |
|-------------------| |----------------------|
| 1. Request data | <---------> | 2. Send certificate |
| 3. Encrypt with | | 4. Decrypt using |
| server’s pub | | private key |
| 5. Send encrypted | | 6. Send response |
| data to server | | encrypted with |
±------------------+ | shared key |
±---------------------+
通过图示可以更清晰地看到客户端与服务器在 SSL/TLS 握手过程中如何进行加密通信。