什么是 HTTPS？
HTTPS（超文本传输安全协议）不是一个新协议，而是HTTP + SSL/TLS 协议的组合。它在 HTTP 的基础上，通过 SSL/TLS 实现了数据的加密传输和服务器身份验证，解决了 HTTP 明文传输的安全漏洞。
臭名昭著的"运营商劫持"
- 简单说就是互联网服务提供商（ISP）利用自身掌控的网络链路控制权，拦截、篡改用户的网络流量.
- 其核心逻辑是：用户的网络请求（如访问网站、加载数据）必须经过运营商的网络设备，部分运营商会在这个 "必经之路" 上植入恶意策略，要么篡改数据、要么重定向流量，最终达到广告变现、窃取数据或限制竞争的目的。
例如：
- 下载⼀个天天动听未被劫持的效果,点击下载按钮,就会弹出天天动听的下载链接.
- 已被劫持的效果,点击下载按钮,就会弹出QQ浏览器的下载链接
什么是加密？
加密就是将明文数据（比如你输入的密码）通过特定算法转换成乱码（密文），只有拥有 "钥匙" 的接收方才能将其还原成明文。核心目的是防止数据在传输过程中被第三方窃取后直接读懂。
在这个加密和解密的过程中,往往需要⼀个或者多个中间的数据,辅助进⾏这个过程,这样的数据称为密钥
两种核心加密技术：对称加密 vs 非对称加密
HTTPS 没有单独用某一种加密，而是结合了两者的优势，先看它们的核心区别：
| 对比维度 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1 个（加密和解密用同一把 "钥匙"） | 2 个（公钥加密，私钥解密，成对出现） |
| 速度 | 快（适合大量数据加密） | 慢（适合小数据加密） |
| 安全性 | 密钥一旦泄露，数据就会被破解 | 私钥仅自己持有，安全性更高 |
| 代表算法 | AES、DES | RSA、ECC |
HTTPS 的工作过程：如何结合两种加密？
HTTPS 的核心是 "用非对称加密传密钥，用对称加密传数据"，具体分 4 步：
- 客户端发起请求 ：你在浏览器输入
https://xxx，浏览器会向服务器发送 "握手请求"，包含浏览器支持的 SSL/TLS 版本、加密算法列表等。 - 服务器身份验证 ：服务器收到请求后，会返回自己的数字证书（包含服务器公钥、网站域名、证书有效期等信息）。
- 客户端验证证书并生成对称密钥 ：
- 浏览器会校验证书的合法性（比如是否由权威机构颁发、域名是否匹配、是否过期）。
- 验证通过后，浏览器生成一个随机的对称密钥，并用服务器证书里的 "公钥" 加密这个对称密钥，再发给服务器。
- 双方用对称密钥传输数据 ：
- 服务器收到加密后的对称密钥，用自己的 "私钥" 解密，得到真正的对称密钥。
- 之后客户端和服务器的所有数据传输，都用这个对称密钥加密和解密（因为对称加密速度快，适合大量数据）。
中间人攻击：HTTPS 要防的核心风险
中间人攻击（MITM）是指第三方（黑客）在客户端和服务器之间 "插一脚"，伪装成双方的 "中间人" 窃取或篡改数据。
- 比如你给服务器发消息，黑客先截获，篡改后再发给服务器；服务器的回复，黑客也先截获，篡改后再发给你。
- HTTP 因为是明文，完全无法防 MITM；而 HTTPS 通过证书验证 和非对称加密，能有效阻止这种攻击 ------ 黑客没有服务器的私钥，无法解密客户端用公钥加密的对称密钥，也伪造不出合法的服务器证书。
⾮对称加密
- 通过公钥对明⽂加密,变成密⽂
- 通过私钥对密⽂解密,变成明⽂
- 也可以反着⽤
- 通过私钥对明⽂加密,变成密⽂
- 通过公钥对密⽂解密,变成明⽂
- 客⼾端在本地⽣成对称密钥,通过公钥加密,发送给服务器.
- 由于中间的⽹络设备没有私钥,即使截获了数据,也⽆法还原出内部的原⽂,也就⽆法获取到对称密钥
- 服务器通过私钥解密,还原出客⼾端发送的对称密钥.并且使⽤这个对称密钥加密给客⼾端返回的响应数据.
- 后续客⼾端和服务器的通信都只⽤对称加密即可.由于该密钥只有客⼾端和服务器两个主机知道,其他主机/设备不知道密钥即使截获数据也没有意义.
- 由于对称加密的效率⽐⾮对称加密⾼很多,因此只是在开始阶段协商密钥的时候使⽤⾮对称加密,后续的传输仍然使⽤对称加密.
那么接下来问题⼜来了:
- 客⼾端如何获取到公钥?
- 客⼾端如何确定这个公钥不是⿊客伪造的?
⿊客可以使⽤中间⼈攻击,获取到对称密钥：
- 服务器具有⾮对称加密算法的公钥S，私钥S'
- 中间⼈具有⾮对称加密算法的公钥M，私钥M'
- 客⼾端向服务器发起请求，服务器明⽂传送公钥S给客⼾端
- 中间⼈劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M， 并将伪造报⽂发给客⼾端
- 客⼾端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加密X，形成报⽂发送给服务器
- 中间⼈劫持后，直接⽤⾃⼰的私钥M'进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加密后，将报⽂推送给服务器
- 服务器拿到报⽂，⽤⾃⼰的私钥S'解密，得到通信秘钥X
- 双⽅开始采⽤X进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚 ⾄修改，都是可以的
证书：证明服务器 "身份" 的 "身份证"
证书全称 "数字证书"，相当于服务器在网络上的 "身份证"，由权威的 CA 机构（比如 Let's Encrypt、Verisign）颁发，核心作用是：
- 证明身份：告诉客户端 "我就是你要访问的 xx 网站，不是黑客伪装的"。
- 提供公钥：证书里包含服务器的公钥，供客户端加密对称密钥使用。
- 浏览器会预装所有权威 CA 机构的 "根证书"，收到服务器证书后，会用根证书验证服务器证书的合法性 ------ 如果证书是伪造的（比如黑客自己做的），浏览器会弹出 "不安全" 警告。
数字签名：防止证书 / 数据被篡改
数字签名是给数据 "盖个章"，证明数据没被篡改，且确实是某个主体发的，核心原理是 "用私钥签名，用公钥验签"：
- 签名过程：比如 CA 机构给服务器发证书时，会先对证书内容（公钥、域名等）计算一个 "哈希值"（相当于数据的 "指纹"，数据变了哈希值就变），再用 CA 自己的 "私钥" 对这个哈希值加密 ------ 这就是数字签名，会附在证书后面。
- 验签过程 ：浏览器收到证书后，先用 CA 的 "公钥" 解密数字签名，得到 CA 计算的哈希值；再自己重新计算证书内容的哈希值，对比两者是否一致。
- 如果一致：证明证书没被篡改，且确实是 CA 颁发的。
- 如果不一致：说明证书被篡改过，浏览器会判定为不安全。
中间⼈有没有可能篡改该证书？
- 中间⼈篡改了证书的明⽂ 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后 的证书形成匹配的签名
- 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改， 证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈
中间⼈整个掉包证书？
- 因为中间⼈没有CA私钥，所以⽆法制作假的证书
- 所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包
- 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
- 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的
为什么签名不直接加密，⽽是要先hash形成摘要?
缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度
完整流程
左侧都是客⼾端做的事情,右侧都是服务器做的事情.
总结 HTTPS⼯作过程中涉及到的密钥有三组.
- 第⼀组(⾮对称加密):⽤于校验证书是否被篡改.服务器持有私钥(私钥在注册证书时获得),客⼾端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥).服务器使⽤这个私钥对证书的签名进⾏加密.客⼾端通过这个公钥解密获取到证书的签名,从⽽校验证书内容是否是篡改过.
- 第⼆组(⾮对称加密):⽤于协商⽣成对称加密的密钥.服务器⽣成这组私钥-公钥对,然后通过证书把钥传递给客⼾端.然后客⼾端⽤这个公钥给⽣成的对称加密的密钥加密,传输给服务器,服务器通过私钥 解密获取到对称加密密钥
- 第三组(对称加密):客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.其实⼀切的关键都是围绕这个对称加密的密钥.其他的机制都是辅助这个密钥⼯作的.第⼆组⾮对称加密的密钥是为了让客⼾端把这个对称密钥传给服务器.第⼀组⾮对称加密的密钥是为了让客⼾端拿到第⼆组⾮对称加密的公钥.