https://blog.csdn.net/qscftqwe/article/details/157142204
这是上节课内容，欢迎大家观看，谢谢了！
一.HTTPS协议
HTTPS 是什么：
HTTPS 也是一个应用层协议 ，是在 HTTP 协议的基础上引入了一个加密层。
HTTP 协议内容都是按照文本的方式明文传输的 ，这就导致在传输过程中可能出现被篡改的情况。
1.1 什么是加密
加密就是把明文 （要传输的信息）变成密文
解密就是把密文再进行一系列变换，还原成明文
在这个加密和解密的过程中，往往需要一个或多个中间的数据 ，辅助进行这个过程，这样的数据称为密钥。
1.2 常见的加密方式
1.对称加密
介绍：
采用单密钥的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单密钥加密，特征：加密和解密所用的密钥是相同的
常见对称加密算法（了解）：DES、3DES、AES、TDEA、Blowfish、RC2等
特点：
算法公开、计算量小、加密速度快、加密效率高
对称加密其实就是通过同一个"密钥"，把明文加密成密文，并且也能把密文解密成明文
例子：
一个简单的对称加密,按位异或
假设明文
a = 1234，密钥key = 8888。则加密
a ^ key得到的密文b为9834。然后针对密文
9834再次进行运算b ^ key，得到的就是原来的明文1234。按位异或只是最简单的对称加密，HTTPS 中并不是使用按位异或。
2.非对称加密
介绍：
需要两个密钥来进行加密和解密，这两个密钥是公开密钥 （简称公钥）；私有密钥（简称私钥）
常见非对称加密算法（了解）：RSA，DSA，ECDSA；
特点：算法强度复杂、安全性依赖于算法与密钥，但加密解密速度比对称加密慢很多。
特点：
非对称加密要用到两个密钥：一个叫做"公钥 "，一个叫做"私钥"；
公钥和私钥是配对的；
最大的缺点是运算速度非常慢，比对称加密慢很多；
通过公钥加密，可用私钥解密；也可以反着用：通过私钥加密，用公钥解密。
例子：
非对称加密的数学原理比较复杂，涉及到一些数论相关的知识，这里举一个简单的生活上的例子。
A 要给 B 一些重要的文件，但是 B 可能不在，于是 A 和 B 提前做出约定。
B 说：我桌子上有个盒子，然后我给你一把锁，你把文件放盒子里用锁锁上，我回头拿着钥匙来开锁取文件。
在这个场景中，这把锁就相当于公钥，钥匙就是私钥 ；公钥给谁都行（不怕泄露），但私钥只有 B 自己持有 ；持有私钥的人才能解密。
1.3 数据指纹（数据摘要）
数字指纹 ，其基本原理是利用单向散列函数 （Hash函数）；数字指纹并不是一种加密机制 ，但可以用来判断数据有没有被篡改，因为只要改一下那么对数据采用同样的单向散列函数生成的值就不一样！
摘要常见算法：MD5、SHA1、SHA256、SHA512 等 ；算法把无限的输入映射成有限的输出 ，因此可能会有碰撞 （两个不同的信息算出相同摘要），但概率非常低。
摘要特征：和加密算法的区别是，摘要严格意义上不是加密，因为没有解密过程 ；从摘要很难反推原信息 ，通常用来进行数据对比。
数据指纹和Cookie联动：
- 服务器在维持每个 Session 唯一性的基础上，结合客户端数据指纹进行绑定，使得该用户在非原始设备或浏览器环境中即使持有有效 Cookie 也会被拒绝访问，从而有效防范会话盗用。
1.4 数字签数据指纹经过加密就叫做数据签名
- 签名的形成是基于非对称加密算法的
为什么不直接把数据加密，而是先把数据形成数据摘要，然后对摘要进行加密呢？
先哈希再签名，不是因为"数据太长加密不了"（虽然这也是事实），
而是因为：哈希提供高效、可靠的完整性校验 ，而私钥签名将该完整性与身份绑定，
共同构成安全、高效、标准化的数字签名机制。
二.HTTPS通信方案
方案 1-只使用对称加密
- 如果通信双方都各自持有同一个密钥 X，且没有别人知道 ，这两方的通信安全当然是可以被保证的（除非密钥被破解）。
特点：
引入对称加密之后，即使数据被截获，由于黑客不知道密钥是啥，因此就无法进行解密，也就不知道请求的真实内容是啥了。
但事情没这么简单：服务器同一时刻其实是给很多客户端提供服务的 ，每个客户端用的密钥都必须不同 （如果相同，密钥就太容易扩散，黑客也可能拿到）。
因此，服务器就需要维护每个客户端和对应密钥之间的关联关系 ，这也是个很麻烦的事情，因此方案一不考虑。
方案 2-只使用非对称加密
- 服务器持有公钥S和私钥S'
鉴于非对称加密的机制，如果服务器先把公钥以明文方式传输给浏览器 ，之后浏览器向服务器传数据前都先用这个公钥加密再传，从客户端到服务器信道似乎是安全的 （但实际仍有安全问题 ），因为只有服务器有相应的私钥能解开公钥加密的数据。
方案3-双方都使用非对称加密
- 服务端拥有公钥S与对应的私钥S'，客户端拥有公钥C与对应的私钥C'
方案 4-非对称加密+对称加密
服务端具有非对称公钥 S 和私钥 S'。
客户端发起 HTTPS 请求，获取服务端公钥 S。
客户端在本地生成对称密钥 C ，通过公钥 S 加密后发送给服务器。
由于中间的网络设备没有私钥 S'，即使截获了数据，也无法还原出对称密钥 C。
服务器通过私钥 S' 解密 ，还原出客户端发送的对称密钥 C ，并使用该密钥加密返回的响应数据。
后续客户端和服务器的通信都只用对称加密 。该密钥只有客户端和服务器知道 ，其他设备即使截获数据也无法解密。
由于对称加密效率远高于非对称加密，因此仅在密钥协商阶段使用非对称加密，后续通信全部使用对称加密。
看起来方案四好像没啥问题，不过如果中间设备在客户端第一步就截取信息会怎么样呢！
中间人攻击（MITM攻击）
确实，在方案2/3/4中，在完成前面两步后，中间人确实无法窃取到数据 ；但是，如果中间人的攻击在最开始握手协商时就介入，那就不一定安全了。
假设 Hacker 已经一开始就成功成为中间人，下面我会用方案四作为例子，因为它是方案二、三的升级版
攻击开始：
服务器具有非对称加密算法的公钥 S 和私钥 S'。
中间人具有非对称加密算法的公钥 M 和私钥 M'。
客户端向服务器发起请求，服务器明文传送公钥 S 给客户端。
中间人劫持数据报文，提取公钥 S 并保存 ，然后将公钥 S 替换为自己的公钥 M，并将伪造报文发给客户端。
客户端收到报文，误以为公钥 M 是服务器的公钥 ，生成对称密钥 C，并用公钥 M 加密 C 发送给服务器。
中间人劫持该报文，用自己的私钥 M' 解密，获取对称密钥 C ，再用之前保存的服务器公钥 S 重新加密 C，转发给服务器。
服务器用私钥 S' 解密，得到对称密钥 C。
注意：中间人的密钥你可以理解位MC因为密钥C是由M加密的，服务器的密钥你可以理解为SC因为密钥C是由S加密的
双方开始使用 C 进行对称加密通信，但整个通信已被中间人完全掌控 ：可窃听、可篡改。（因为双发发的是以M加密的MC和以S'加密的S'C，这两个中间人有对于的私钥M'和公钥S）
问题本质出在哪里了呢?客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的!
2.1 证书
CA认证：
服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书 ，数字证书里含有证书申请者信息、公钥信息等 。服务器把证书传输给浏览器，浏览器从证书里获取公钥 就行了。证书就如身份证，证明服务端公钥的权威性。
如果没有证书就会出现这种，因此证书的重要性不言而喻
证书重要部分讲解：
申请证书时，会生成公钥和私钥，这两个是给公司的。
证书是用来安装到服务器上的，它位于签发证书的后面（图中未显示）。
数字签名中使用的私钥和公钥是 CA 机构的，不是公司的公钥和私钥 ------ 这一点需要记住。
方案5-非对称加密+对称加密+证书认证
在客户端和服务器刚一建立连接的时候，服务器给客户端返回一个证书 ，证书包含了之前服务端的公钥，也包含了网站的身份信息。
方案五其实就是在方案四的基础上加一个证书认证。
如何解决中间人问题：
方案四的问题在于：在客户端与服务器初始通信时，若中间人介入并替换服务器的公钥，客户端无法验证该公钥的真实性，从而导致后续通信被窃听或篡改。
方案五通过引入数字证书解决此问题：服务器在通信开始时发送由可信 CA（证书颁发机构）签发的证书，其中包含其公钥和身份信息（如域名）。此时，即使中间人截获并试图篡改该证书，也无法绕过以下安全机制：
若仅篡改证书内容（如域名或公钥），客户端在验证签名时会发现数据摘要不匹配，从而判定证书无效；
若同时篡改内容并尝试重新签名，由于中间人没有 CA 的私钥，无法生成合法签名；而客户端使用内置的 CA 公钥解密签名时，将无法得到有效的原始摘要，验证仍会失败；
若中间人使用自己申请的合法证书进行"掉包"，该证书中的域名必然与其所冒充的目标域名（不一致），浏览器会立即检测到域名不匹配并阻止连接。
方案五在理论上是安全的，它正是 HTTPS（基于 TLS/SSL 协议）所采用的核心机制。
完整流程：
总结：
一开始服务器有公钥 S 和私钥 S' ， 在客户端发起请求时，服务器发送证书 （该证书携带了公钥 S），客户端内置了 CA 公钥 （以受信任根证书形式存在），通过 CA 验证服务器证书 ，从而安全获取公钥 S ，客户端生成对称密钥 C ，并用公钥 S 加密 C 后发送给服务器 ，服务器用私钥 S' 解密 得到密钥 C，此后，双方使用密钥 C 进行对称加密通信。
服务器持有：公钥 S、私钥 S'、密钥 C
客户端持有：CA 公钥（用于验证，内置的）、公钥 S（从证书中提取）、密钥 C
关于HTTPS的内容就到这里结束了，下期我会大家来到传输层带着大家理解UDP和TCP，其中TCP是重点中的重点，知识点很多！