HTTPS 加密流程深度解析
- [1.为什么需要 HTTPS?](#1.为什么需要 HTTPS?)
- [2. 加密过程](#2. 加密过程)
- [2.1 在HTTP基础上引入对称密钥](#2.1 在HTTP基础上引入对称密钥)
- [2.2 使用非对称密钥加密，尝试传递对称密钥](#2.2 使用非对称密钥加密，尝试传递对称密钥)
- [2.3 漏洞：非对称加密场景下的中间人攻击](#2.3 漏洞：非对称加密场景下的中间人攻击)
- [2.4 引入数字证书，防止中间人攻击](#2.4 引入数字证书，防止中间人攻击)
- [3. HTTPS‑TLS 完整握手加密流程](#3. HTTPS‑TLS 完整握手加密流程)
- [4. HTTPS加密流程总结](#4. HTTPS加密流程总结)
前言：
这里是小谢同学的HTTPS加密过程心得，整理HTTPS加密过程。笔记用于自我复盘巩固，有错误欢迎大家指出，专栏还有 Java、网络、C 语言系列笔记欢迎翻阅,同时也希望我的见解对你有帮助~
为什么需要 HTTPS?
早期的 HTTP 协议属于明文传输协议 ，客户端与服务器交互的所有的报文都会原封不动地在网络中传播，因此带来了三大安全风险：
- 窃听风险：中间人抓包就可以直接读取账号、密码等敏感数据，造成隐私泄露。
- 篡改风险：攻击者截获报文后，可以随意修改报文内容，服务器并不会识别报文已经被修改过。
- 冒充风险：黑客伪装成正规网站接收客户端请求，诱导用户访问钓鱼网站(类似于间谍)。
为了解决以上的三个问题，HTTPS 应运而生。HTTPS 并不是全新的协议 ，本质就是 HTTP + TLS 。HTTP 负责业务数据交互，TLS 负责通信加密，在 TCP 和 HTTP 之间建立一条安全的加密通道。
加密过程
HTTPS 的加密方案并不是一步成型的，而是一步一步实践中不断形成的;我们顺着方案迭代演进的思路，一步步推导出最终成熟安全的 HTTPS 通信方案。
在HTTP基础上引入对称密钥
想要解决明文被窃听这一个问题,最先想到的就是使用钥匙上锁(也就是对称密钥,既可以上锁也可以解锁)
对称密钥的特点:
- 加密和解密使用同一把密钥。客户端使用密钥将明文加密成密文再发送；服务器收到密文后再用同一把密钥解密还原数据。
但是此时也面临了一个问题:
这把共享的对称密钥该如何安全给到对方?如果直接通过网络传输密钥，密钥本身就有被中间人截获的风险。一旦密钥泄露，后续所有加密的数据都会被解开。
因此
密钥的传输也必须加密传输;仅依靠对称加密，只能加密业务数据，却无法安全传递密钥。
使用非对称密钥加密，尝试传递对称密钥
为了解决密钥传递难题，我们引入非对称加密。
非对称密钥:分为公钥和私钥,公钥可以对外公开；私钥由服务器本地保管。公钥加密的数据，只能由对应的私钥解密。(当然也可以私钥加密,公钥解密)
- 服务器生成一对
公钥私钥，将公钥明文发送给客户端。客户端生成一把用于后续通信的对称密钥，使用服务器的公钥加密它。- 客户端把加密后的
密钥发送给服务器。- 服务器使用
私钥解密报文，得到客户端生成的对称密钥。
为什么后续传输的数据使用对称密钥加密而不是非对称密钥加密?
- 运算速度差距巨大
- 非对称加密 ：CPU 开销极大，速度慢
- 对称加密 ：加解密速度极快，比非对称加密快几个数量级
举个直观例子：非对称加密加密 1MB 数据可能要几百毫秒，对称加密只要几微秒。
但是此时就安全了吗?黑客就没有办法了吗?答案是否定的
漏洞：非对称加密场景下的中间人攻击
服务器下发公钥的时候依旧是明文传输，黑客手里也拥有公钥啊,不只是客户端有(此时的黑客就是中间人)
- 服务器将自己真实的
公钥发送给客户端。- 中间人
截获报文，扣下服务器的公钥，将自己伪造的公钥发送给客户端,此时客户端并不知道这个是中间人的公钥,无法辨别。- 客户端误把
黑客伪造的公钥当成网站公钥，加密生成好的对称密钥，发送出去。- 中间人截获报文，用
自己的私钥解密，拿到对称密钥。至此双方通信密钥已经被黑客掌握。- 中间人再用服务器
真实的公钥加密对称密钥，转发给服务器。服务器全程察觉不到通信被劫持,此时也不知道这是被修改的数据。
就是类似于碟中谍,充当两边交互的人员;从而获取情报;
引入数字证书，防止中间人攻击
数字证书由权威第三方机构 CA（证书颁发机构，相当于互联网世界的公证人）签发(这份证书就类似于我们的身份证,每一个人都有独一无二的身份证)。
申请证书完整流程：
- 网站服务器将自己的域名、服务器公钥提交给 CA 机构。
- CA 审核信息后，使用
CA 自己的私钥，对网站信息生成数字签名。- CA 将
网站域名、服务器公钥、CA 签名、有效期打包成一份完整的数字证书，颁发给网站服务器注意:
签名是 CA 生成的，服务器并不掌握 CA 的私钥，服务器只负责保管这份证书。
当 HTTPS 连接建立时，服务器不会单独下发公钥，而是直接把 CA 颁发给自己的完整数字证书发送给客户端（浏览器） 。
客户端收到证书之后就会进行验签
验签:
- 会读取提前保留在操作系统中
内置的可信 CA 列表(像我们的电脑,只要不是杂牌,基本上每一个电脑内都保存了对应CA公钥)- 使用 CA 公钥解密证书中的数字签名，得到哈希摘要 A。
- 客户端读取证书正文内容，本地会重新计算哈希摘要，得到结果 B。
- 对比 A 与 B：相等，代表证书没有被篡改；不相等，证书已被改动，浏览器抛出不安全警告，终止连接。
中间人
即使截获报文，用他自己电脑内部的CA 的公钥，也无法伪造合法证书。因为黑客没有CA 的私钥，篡改证书后生成不出合法签名 ，验签一定会失败。
HTTPS‑TLS 完整握手加密流程
TLS 握手流程中，客户端收到服务器返回的证书，完成证书校验。（以 TLS1.2 为例）
- 客户端发送 Client Hello
客户端发送握手起始报文 ，携带客户端支持的 TLS 版本、客户端随机数Client‑Random、加密套件列表。 - 服务器返回 Server Hello + 数字证书
服务器选定双方兼容的 TLS 版本，生成服务器随机数Server‑Random，挑选一套加密套件，连同数字证书一起返回客户端。 - 客户端校验证书，生成预主密钥
客户端校验证书合法之后，本地随机生成一份预主密钥 Pre‑Master‑Secret，使用证书内的服务器公钥加密预主密钥，发送给服务器。
注意：网络传输的是加密后的
预主密钥密文，原始预主密钥不会裸奔传输。
- 服务器解密获取预主密钥
服务器收到报文后，使用本地保存的私钥解密报文，拿到预主密钥。 - 双方本地推导生成会话密钥（对称密钥）
此时客户端与服务器两边，都集齐三份随机素材：Client‑Random、Server‑Random、Pre‑Master‑Secret。双方使用相同的密钥推导算法，在本地各自运算，生成一模一样的会话密钥。会话密钥全程不会经过网络传输。
为什么要有这3份随机素材?
- 保证每一次 HTTPS 会话的会话密钥都不重复->如果没有这三份随机数,同一个客户端与服务器交互过程中可能出现
一模一样的会话密钥,如果哪次密钥泄露了,就会产生严重问题,使用随机数即使这次会话密钥被解密也只是泄露这一段会话的信息- 提升密钥的熵（
随机性），抵抗暴力方法破解->只靠单独一份随机源，有可能出现随机数质量差的情况。把客户端、服务端、客户端预主密钥三份独立随机来源混合在一起，最终的会话密钥的不可预测性会大幅提高，黑客暴力猜解密钥的难度变大。- 抵御重放攻击->黑客抓包拿到
过去完整的握手报文，直接原样重放发送给服务器。但因为每一次握手的Client‑Random/Server‑Random都是全新随机，推导出来的会话密钥完全不一样，旧握手包无法复用冒充合法连接。
- 握手收尾，切换加密通信
客户端发送Change‑Cipher‑Spec报文，通知服务器后续报文启用对称加密；再发送一条被会话密钥加密过的 Finished(FIN) 报文。服务器同样返回对应报文，校验握手完整性。
至此 TLS 握手完成，后续所有 HTTP 业务报文，都依靠会话密钥(对称密钥)进行对称加密传输。
HTTPS加密流程总结
- HTTP 的原始缺陷
HTTP 直接明文传输数据，攻击者不需要攻破路由器，只需要劫持网络链路抓包，就能窃取全部通信的明文数据。为解决窃听问题，诞生了 HTTPS。HTTPS = HTTP + TLS，TLS 介于 TCP 与 HTTP 之间，搭建加密安全通道。
- 对称加密的出现与困境
使用对称加密对业务数据加密，通信双方共用同一把密钥完成加密解密。但是出现难题：生成会话密钥的种子（预主密钥）该如何安全给到服务器，直接网络传输会被黑客截获。
- 引入非对称加密，解决种子传递，但暴露中间人攻击
服务器生成非对称公私钥对；握手时服务器把公钥下发给客户端。
客户端使用服务器公钥加密自己生成的预主密钥 Pre‑Master‑Secret发送给服务器，服务器用私钥解密拿到预主密钥。
漏洞：中间人攻击。中间人拦截服务器公钥，替换为自己伪造的公钥发给客户端；客户端用中间人公钥加密预主密钥。
中间人用自己私钥解密拿到预主密钥，再拿真实服务器公钥加密转发给服务器。中间人掌握密钥种子，全部通信被劫持，两端毫无感知。
- CA 数字证书解决中间人公钥篡改问题
服务器向 CA 权威机构提交资质申请证书。CA 使用自身私钥对网站信息生成数字签名，把网站域名、服务器公钥、签名、有效期打包成数字证书颁发给服务器。
TLS 握手过程中服务器把证书下发给客户端。客户端使用操作系统预装的 CA 根公钥验签：解密签名得到哈希摘要 A；
本地对证书正文重新计算哈希得到摘要 B。A 与 B 相等，证书合法未篡改，客户端拿到真实可靠的服务器公钥；不相等直接断开连接。
5.TLS 握手，本地推导会话密钥（会话密钥不会走网络）
- 客户端发送握手报文：携带 TLS 版本、
Client‑Random客户端随机数、加密套件列表。- 服务器返回：选定兼容的 TLS 版本、生成
Server‑Random服务端随机数、选定加密套件、下发数字证书。- 客户端校验证书通过，生成预主密钥 Pre‑Master‑Secret，用服务器公钥加密发送。
- 服务器私钥解密，拿到预主密钥。
- 两端集齐三份随机素材：
Client‑Random、Server‑Random、Pre‑Master‑Secret。两端使用同一套密钥派生算法，各自本地独立运算，生成完全一致的会话密钥。会话密钥全程只存在两端内存，不会在网络传输。
- 握手
两端使用生成好的会话密钥互相发送
Finished加密报文，验证双方确实算出相同会话密钥，确认握手没有被篡改。握手完成，后续 HTTP 业务数据全部使用会话密钥做对称加密传输。
注意:安全不是绝对的,即使这样做了也达不到100%的安全,这取决于攻击者想要获取什么数据,收益和付出是否对等;
