HTTPS 原理技术

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 相关数据；
- [B] 向 CA 机构申请数字证书，并将证书部署到服务器；
- [C] HTTPS 作用过程简述：
  - [C-1] 客户端发起 HTTPS 请求；
  - [C-2] 服务器把数字证书返回给客户端；
  - [C-3] 客户端校验数字证书合法后，从中取出服务器公钥，并生成一个随机码，用公钥对随机码进行加密；
  - [C-4] 客户端将公钥加密后的随机码发送给服务器；
  - [C-5] 服务器使用私钥解密得到随机码；
  - [C-6] 客户端和服务器根据双方之前通信交换的信息（包括随机码）生成同样的密钥，后续使用此密钥对通信信息进行对称加密。