HTTPS原理技术
背景
随着年龄的增长，很多曾经烂熟于心的技术原理已被岁月摩擦得愈发模糊起来，技术出身的人总是很难放下一些执念，遂将这些知识整理成文，以纪念曾经努力学习奋斗的日子。本文内容并非完全原创，大多是参考其他文章资料整理所得，感谢每位技术人的开源精神。
简介
HTTPS 中的 S 是 Secure 的缩写，是在 HTTP 基础上增加了一个安全层，通过加密等手段保证传输数据安全。
早期 HTTPS 使用 SSL （Secure Socket Layer，安全套接字层） 协议，从 SSL 3.1 开始 IETF 将其标准化并重命名为 TLS（Transport Layer Security，传输层安全），目前最新的 TLS 版本是 2018 年发表的 TLS 1.3，但应用最为广泛的是 2008 年发表的 TLS 1.2。
因此 HTTPS = HTTP + SSL/TLS 。
原理
下面通过实际场景逐步说明 HTTPS 的原理。
-
HTTP 通信过程中，所有的消息（message）都是明文传输，一旦遇到非法中间人（如黑客）监听拦截，便可获取所有的传输消息并进行伪造，如下图所示。
-
为解决传输数据安全的问题，通信的双方决定采用 对称加密 技术对消息进行加密，这样中间人最多只能获取加密后的密文，没有密钥的话不能伪造任何消息，伪造的消息到达消息接收方后无法被正确解密。
此方案仍然存在两个问题：
① 使用相同密钥的情况下，如果通信存在多方，那么所有的通信消息都使用相同的密钥加解密，因此通信相当于是透明的，中间人可以伪装成一个合法的通信方，拿到密钥后便可获取所有的通信消息。
② 使用相同密钥的情况下，密钥只能在通信的一方生成，如何传递给通信的另一方，如何解决密钥传递过程的安全问题？
-
解决以上两个问题的关键是：
① 通信双方必须使用独立且唯一的密钥对通信消息进行加解密，这个密钥只有这两者知道，不能透露给任何第三方。
② 密钥必须以加密方式进行传递。
因此通信的双方决定先采用 非对称加密 技术生成一个密钥对，然后拥有公钥的一方生成一个随机密钥，通过公钥加密后将此密钥发给另一方，另一方使用私钥解密后拿到相同的随机密钥，后续的通信过程就使用此随机密钥进行消息加解密，如下图所示。
此方案仍然存在问题：拿到公钥的 A 怎么能确保公钥的合法性？中间人完全可以先伪装成 A 拿到来自 B 的公钥 KEY1，然后生成自己的密钥对，将自己生成的公钥 KEY2 伪装成合法的公钥发送给 A，后续通信过程中 A 会使用拿到的公钥 KEY2 对消息进行加密并发送，中间人截取到后使用自己的私钥解密获取通信消息原文，然后伪造通信消息并使用合法公钥 KEY1 进行加密后发送给 B。
-
为解决公钥信任问题，引入了数字证书技术，以下便是 HTTPS 原理示意图。
实现 HTTPS 的整个过程分为三大阶段：
-
A\] 客户端内置 CA 公钥，以浏览器为例，各大浏览器厂商在发行版本中已内置 CA 相关数据；
-
C\] HTTPS 作用过程简述： * \[C-1\] 客户端发起 HTTPS 请求； * \[C-2\] 服务器把数字证书返回给客户端； * \[C-3\] 客户端校验数字证书合法后，从中取出服务器公钥，并生成一个随机码，用公钥对随机码进行加密； * \[C-4\] 客户端将公钥加密后的随机码发送给服务器； * \[C-5\] 服务器使用私钥解密得到随机码； * \[C-6\] 客户端和服务器根据双方之前通信交换的信息（包括随机码）生成同样的密钥，后续使用此密钥对通信信息进行对称加密。
-
本文聚焦对 HTTPS 原理的说明，对于 HTTPS 使用到的对称加密、非对称加密、数字证书、数字签名等技术及 SSL/TLS 等协议将在后续文章中做出更加详细的说明。