🔥个人主页： Milestone-里程碑
❄️个人专栏: <<力扣hot100>> <<C++>><<Linux>>
🌟心向往之行必能至
目录
[一 .HTTPS 是什么](#一 .HTTPS 是什么)
[2.1 什么是"加密"](#2.1 什么是"加密")
[2.2 为什么要加密](#2.2 为什么要加密)
[3.1 方案一:只使用对称加密](#3.1 方案一:只使用对称加密)
[3.2 方案二:只使用非对称加密](#3.2 方案二:只使用非对称加密)
[3.3 方案三:双方都使用非对称加密](#3.3 方案三:双方都使用非对称加密)
[3.4 方案四:⾮对称加密 + 对称加密](#3.4 方案四:⾮对称加密 + 对称加密)
[步骤 1：服务器提前准备非对称密钥对](#步骤 1：服务器提前准备非对称密钥对)
[步骤 2：客户端发起通信，生成对称密钥 X](#步骤 2：客户端发起通信，生成对称密钥 X)
[步骤 3：客户端完成 "双重加密"，发送数据](#步骤 3：客户端完成 “双重加密”，发送数据)
[步骤 4：服务器解密，得到对称密钥 X](#步骤 4：服务器解密，得到对称密钥 X)
[步骤 5：双方用对称密钥 X 通信](#步骤 5：双方用对称密钥 X 通信)
[3.5 中间人攻击](#3.5 中间人攻击)
[3.6 数据摘要:解决中间人攻击](#3.6 数据摘要:解决中间人攻击)
[3.7 ⽅案 5 - ⾮对称加密 + 对称加密 + 证书认证](#3.7 ⽅案 5 - ⾮对称加密 + 对称加密 + 证书认证)
[3.7.3 中间人是否可以调包证书?](#3.7.3 中间人是否可以调包证书?)
一 .HTTPS 是什么
HTTPS 也是⼀个应⽤层协议. 是在 HTTP 协议的基础上引⼊了⼀个加密层.
HTTP 协议内容都是按照⽂本的⽅式明⽂传输的. 这就导致在传输过程中出现⼀些被篡改的情况.
二.概念认识
2.1 什么是"加密"
加密就是把 明⽂ (要传输的信息)进⾏⼀系列变换, ⽣成 密⽂ .
解密就是把 密⽂ 再进⾏⼀系列变换, 还原成 明⽂
加密是为了安全
2.2 为什么要加密
臭名昭著的 "运营商劫持"
如果没有进行加密,假设你要下载A软件, 给服务器发送了⼀个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该A的 APP 的下载链接,但被劫持后,可以将用户的下载链接改为软件B的
2.3常见的加密方式
对称加密
采⽤单钥 密码系统 的加密⽅法，同⼀个 密钥 可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的
常⻅对称加密算法(了解)： DES 、 3DES 、AES、TDEA、 Blowfish 、RC2等
特点：算法公开、计算量⼩、加密速度快、加密效率⾼
非对称加密
需要两个 密钥 来进⾏加密和解密，这两个密钥是 公开密钥 （public key，简称公钥）和私有密钥（private key，简称私钥）。
• 常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA
• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快。
使用:利用公钥对明文进行加密,解密则只能使用那唯一的密钥进行解密,也可反用
数据摘要 && 数据指纹
数字指纹(数据摘要),其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算,⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制,但可以⽤来判断数据有没有被篡改。
• 摘要常⻅算法：有 MD5 、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低）
• 摘要特征：和 加密算法 的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常⽤来进⾏数据对⽐
使用Hash进行摘要,我们知道,哪怕修改了一个比特位,利用Hash进行摘要的结果也相差很大,数据摘要主要是验证数据是否被篡改
例子:
如你上传一部电影到网盘,其中就通过数据摘要对资源进行加工存储
假设小李上传的电影和你一样,网盘的服务器通过数据摘要发现已经存储过了,此处小李就可以不用上传了,变为了秒传
你的账号与密码,账号正常存储,密码用数据摘要存储,验证再对你输入的密码通过同样的Hash映射对比,
这即保证了防止被黑客攻击的安全,也保证了防止你的密码被服务器方的工作人员获取
数字签名
• 摘要经过加密，就得到数字签名（后⾯细说）
理解链 - 承上启下
• 对http进⾏对称加密，是否能解决数据通信安全的问题？问题是什么？
• 为何要⽤⾮对称加密？为何不全⽤⾮对称加密？
三.HTTPS的工作过程探究讲解
3.1 方案一:只使用对称加密
如果通信双⽅都各⾃持有同⼀个密钥X，且没有别⼈知道，这两⽅的通信安全当然是可以被保证的（除⾮密钥被破解）
引⼊对称加密之后, 即使数据被截获, 由于⿊客不知道密钥是啥, 因此就⽆法进⾏解密, 也就不知道请求的真实内容是啥了. 但服务器同⼀时刻其实是给很多客⼾端提供服务的. 这么多客⼾端, 每个⼈⽤的秘钥都 必须是不同的(如果是相同那密钥就太容易扩散了, ⿊客就也能拿到了). 因此服务器就需要维护每个客⼾端和每个密钥之间的关联关系, 这也是个很⿇烦的事情~
那为了确保密钥是安全的,因此密钥的传输也必须加密传输!这不就成了鸡生蛋,蛋生鸡了吗
3.2 方案二:只使用非对称加密
鉴于⾮对称加密的机制，如果服务器先把公钥以明⽂⽅式传输给浏览器，之后浏览器向服务器传数据前都先⽤这个公钥加密好再传，从客⼾端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有相应的私钥能解开公钥加密的数据。
这似乎是安全的,但其实也不安全(下面细讲),且效率过低,
3.3 方案三:双方都使用非对称加密
服务端拥有公钥S与对应的私钥S'，客⼾端拥有公钥C与对应的私钥C',客⼾和服务端交换公钥
客⼾端给服务端发信息：先⽤S对数据加密，再发送，只能由服务器解密，因为只有服务器有私钥
S'
服务端给客⼾端发信息：先⽤C对数据加密，在发送，只能由客⼾端解密，因为只有客⼾端有私钥
C' 这样貌似也⾏啊
但是 效率太低 依旧有安全问题
3.4 方案四: ⾮对称加密 + 对称加密
先解决效率问题
主要有以下5个步骤
步骤 1：服务器提前准备非对称密钥对
服务器生成自己的 非对称密钥对：
- 公钥 S：对外公开，任何客户端都能获取（比如通过 HTTPS 连接时服务器会主动下发）；
- 私钥 S'：服务器自己秘密保存，绝对不泄露。
步骤 2：客户端发起通信，生成对称密钥 X
当客户端要给服务器发数据时：
- 客户端先在本地 随机生成一个对称密钥 X（比如 AES-256 算法的密钥，是一串随机字符串）；
- 客户端获取服务器的 公钥 S（比如从服务器的证书里提取）。
步骤 3：客户端完成 "双重加密"，发送数据
客户端同时做两件事：
- ① 用对称密钥 X 加密业务数据：把要发送的原始 "数据"（比如用户的请求信息），用 X 加密成 "密文数据 XXXX"（对称加密速度快，适合大体积数据）；
- ② 用服务器公钥 S 加密对称密钥 X：把临时生成的 X，用公钥 S 加密（这样只有服务器的私钥 S' 能解密 X）；
- 最后，客户端把 "加密后的 X" 和 "密文数据 XXXX" 一起发给服务器。
步骤 4：服务器解密，得到对称密钥 X
服务器收到客户端发来的内容后：
- 用自己的 私钥 S' 解密 "加密后的 X"，得到原始的对称密钥 X；
- 用解密得到的 X，解密 "密文数据 XXXX"，还原出客户端发送的原始数据。
步骤 5：双方用对称密钥 X 通信
后续客户端和服务器之间的所有 HTTP 数据交换，都直接用 对称密钥 X 进行加密和解密（同一密钥既加密又解密），直到本次通信结束（X 会被销毁，下次通信会重新生成新的 X）。
这个流程的核心是：用非对称加密解决 "密钥安全传递" 的问题，用对称加密解决 "数据高效加密" 的问题，是 HTTPS 等安全通信的核心逻辑。
但依旧不安全
3.5 中间人攻击
• Man-in-the-MiddleAttack，简称" MITM攻击 "
上面的加密方案,如果客⼾端获取到公钥S之后，对客⼾端形成的对称秘钥X⽤服务端给客⼾端的公钥 S进⾏加密，中间⼈即使窃取到了数据，此时中间⼈确实⽆法解出客⼾端形成的密钥X，因为只有服务器有私钥S'
但如果中间人攻击发生在第一次呢
- 服务器具有⾮对称加密算法的公钥S，私钥S'
- 中间⼈具有⾮对称加密算法的公钥M，私钥M'
- 客⼾端向服务器发起请求，服务器明⽂传送公钥S给客⼾端
- 中间⼈劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M,并将伪造报⽂发给客⼾端
- 客⼾端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加密X，形成报⽂发送给服务器
- 中间⼈劫持后，直接⽤⾃⼰的私钥M'进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加密后，将报⽂推送给服务器
- 服务器拿到报⽂，⽤⾃⼰的私钥S'解密，得到通信秘钥X
- 双⽅开始采⽤X进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚⾄修改，都是可以的
3.6 数据摘要:解决中间人攻击
在客户端对服务端发送请求时,会先通过Hash,将明文进行数据摘要,然后对摘要进行签名(由签名者,即CA证书),然后再对明文和这个摘要进行拼接,发送给服务端后,服务端先分开密文和摘要,对密文进行解密然后通过同样的Hash算法与对摘要进行解签之后,看看是否相等,即可
3.6.1CA认证
服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信 息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性
3.7 ⽅案 5 - ⾮对称加密 + 对称加密 + 证书认证
在客⼾端和服务器刚⼀建⽴连接的时候, 服务器给客⼾端返回⼀个 证书，证书包含了之前服务端的公钥, 也包含了⽹站的⾝份信息
3.7.2客⼾端进⾏认证
当客⼾端获取到这个证书之后, 会对证书进⾏校验(防⽌证书是伪造的).
• 判定证书的有效期是否过期
• 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
• 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数 据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对⽐ hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的
3.7.3 中间人是否可以调包证书?
• 因为中间⼈没有CA私钥，所以⽆法制作假的证书(为什么？ 官方认证)
• 所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包
• 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如整
体掉包，客⼾端依旧能够识别出来。
• 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的
3.7.4为什么签名不直接加密，⽽是要先hash形成摘要?
• 缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度
4.工作完整流程
