网络原理（应用层）-＞HTTPS解

前言：
大家好我是小帅，今天我们来了解HTTPS,
个人主页：再无B～U～G

1.HTTPS

1.1HTTPS 是什么？

HTTPS 也是⼀个应⽤层协议. 是在 HTTP 协议的基础上引⼊了⼀个加密层.
HTTP 协议内容都是按照⽂本的⽅式明⽂传输的. 这就导致在传输过程中出现⼀些被篡改的情况.

臭名昭著的 “运营商劫持”
由于我们通过⽹络传输的任何的数据包都会经过运营商的⽹络设备(路由器, 交换机等), 那么运营商的⽹
络设备就可以解析出你传输的数据内容, 并进⾏篡改.

不⽌运营商可以劫持, 其他的 ⿊客 也可以⽤类似的⼿段进⾏劫持, 来窃取⽤⼾隐私信息, 或者篡改内容.
试想⼀下, 如果⿊客在⽤⼾登陆⽀付宝的时候获取到⽤⼾账⼾余额, 甚⾄获取到⽤⼾的⽀付密码…
在互联⽹上, 明⽂传输是⽐较危险的事情!!!

1.2 “加密” 是什么

加密就是把 明⽂ (要传输的信息)进⾏⼀系列变换, ⽣成 密⽂.
解密就是把 密⽂ 再进⾏⼀系列变换, 还原成 明⽂.

在这个加密和解密的过程中, 往往需要⼀个或者多个中间的数据, 辅助进⾏这个过程, 这样的数据称为 密
钥.

1.3 HTTPS 的⼯作过程

既然要保证数据安全, 就需要进⾏ “加密”.
⽹络传输中不再直接传输明⽂了, ⽽是加密之后的 “密⽂”.
加密的⽅式有很多, 但是整体可以分成两⼤类: 对称加密 和 ⾮对称加密.

1.3. 1对称加密

对称加密其实就是通过同⼀个 “密钥” , 把明⽂加密成密⽂, 并且也能把密⽂解密成明⽂.

如果直接把密钥明⽂传输, 那么⿊客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.
**因此密钥的传输也必须加密传输! **

1.3.2⾮对称加密

⾮对称加密要⽤到两个密钥, ⼀个叫做 “公钥”, ⼀个叫做 “私钥”.
私钥加密，公钥解密，这两个是相对的，发布出去的就是公钥
公钥和私钥是配对的. 最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多

那么接下来问题⼜来了

客⼾端如何获取到公钥?
数据的安全传输了吗？
客⼾端如何确定这个公钥不是⿊客伪造的?

1.4中间人攻击

为什么不能明文传输公钥？

假如说在对称加密里面，公钥的传输是明文传输的。
那么就会出现这种情况：

假设服务器和中间人都有能力生成公钥私钥。

1. 客⼾端向服务器发起请求，服务器明⽂传送公钥S给客⼾端。
2. 中间⼈劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M，并将伪造报⽂发给客⼾端。
3. 客⼾端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加密X，形成报⽂发送给服务器。
4. . 中间⼈劫持后，直接⽤⾃⼰的私钥M’进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加密后，将报⽂推送给服务器。
   图解:
   

为了解决中间人攻击问题，引入证书。

1.5 证书

服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信
息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端
公钥的权威性。

1. CA机构拥有⾮对称加密的私钥A和公钥A。
2. 然后对数据摘要⽤CA私钥A’加密，得到数字签名S 。
3. 考虑到CA能颁发CA机构不多，CA公钥也不多所以直接把CA的公钥配置到操作系统里面。

1.5.1 数字签名

签名的形成是基于⾮对称加密算法的，注意，⽬前暂时和https没有关系，不要和https中的公钥私钥搞
混了。
简单来说：就是通过AC私钥加密服务器的数据（公钥，服务器信息）。

通过证书解决解决中间人攻击
根本原因：是公钥是明文传输的，没有办法知道是否被替换。
解决办法：只要知道客户端拿到的公钥是服务器的公钥就可以解决。

1. 客户端请求得到服务器公钥（请求）

2. 服务器收到请求后，使用CA私钥加密（服务器信息和公钥），返回给客户端，
   解释一下这里的问题：
   中间人也有AC公钥啊，也可以解密服务器用AC私钥加密的数据得到公钥。那是否还会出现上面“中间人攻击问题”呢？
   但是要想再发给客户端（发中间人解密的服务器的数据），必须使用AC私钥加密，才能让客户端发现不了证书被解密过。但是只有服务器有AC私钥。所以即使中间人有AC公钥，也无济于事。

3. 客户端使用AC公钥对数字签名进行解密，得到⼀个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对⽐ hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的。

4. 这时候拿到的公钥就是服务器公钥

查看浏览器的受信任证书发布机构

1. 在google浏览器的地址栏，输入如下命令，回车

chrome:
2.点击[管理证书] —> 受信任的根证书颁发机构 —> 详细信息 —> 所有 --> 公钥

2. HTTPS问题

中间⼈有没有可能篡改该证书？
上面我们已经回答了这个问题。

1. 中间⼈篡改了证书的明⽂
2. 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名。
3. 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈。

中间⼈整个掉包证书？

1. 因为中间⼈没有CA私钥，所以⽆法制作假的证书(为什么？)
2. 所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包
3. 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
   永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的

为什么摘要内容在⽹络传输的时候⼀定要加密形成签名?

常⻅的摘要算法有: MD5 和 SHA 系列
以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点:

• 定⻓: ⽆论多⻓的字符串, 计算出来的 MD5 值都是固定⻓度 (16字节版本或者32字节版本)
• 分散: 源字符串只要改变⼀点点, 最终得到的 MD5 值都会差别很⼤.
• 不可逆: 通过源字符串⽣成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.

正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同.

完整流程
左侧都是客⼾端做的事情, 右侧都是服务器做的事情.

总结:
HTTPS ⼯作过程中涉及到的密钥有三组

第⼀组(⾮对称加密): ⽤于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客⼾端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使⽤这个私钥对证书的签名进⾏加密. 客⼾端通过这个公钥解密获取到证书的签名, 从⽽校验证书内容是否是篡改过.
第⼆组(⾮对称加密): ⽤于协商⽣成对称加密的密钥. 服务器⽣成这组 私钥-公钥 对, 然后通过证书把公钥传递给客⼾端. 然后客⼾端⽤这个公钥给⽣成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.
第三组(对称加密): 客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.

为什么第三组要使用对称加密，不一直使用非对称加密呢？而且非对称加密安全的多
回答是：没必要
前两次组加密过程，使客户端和服务器密文获得了对方的公钥和私钥，，不存在中间人攻击安全问题，而且对称加密传输数据比非对称加密快。

好了，今天就到这里了，感谢观看。