HTTPS协议：
HTTPS 也是⼀个应用层协议
HTTPS本质上就是在HTTP的基础上加了一个加密层，抛开加密之后，剩下的内容跟HTTP一样；
HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况.
例如 ：下载一个“天天动听”
正常情况下：点击下载按钮, 就会弹出天天动听的下载链接.
但是可以会出现劫持的效果, 点击下载按钮, 就会弹出 QQ 浏览器的下载链接
由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器, 交换机等), 那么运营商的网络设备就可以解析出你传输的数据内容, 并进行篡改.
点击 "下载按钮", 其实就是在给服务器发送了一个 HTTP 请求, 获取到的 HTTP 响应其实就包含了该 APP 的下载链接. 运营商劫持之后, 就发现这个请求是要下载天天动听, 那么就⾃动的把交给用户的响应给篡改成 "QQ浏览器" 的下载地址了.
不止运营商可以劫持, 其他的黑客也可以用类似的手段进行劫持, 来窃取用户隐私信息, 或者篡改内容.
在互联网上, 明文传输是比较危险的事情!!!HTTPS 就是在 HTTP 的基础上进行了加密, 进一步的来保证用户的信息安全~
加密：
加密就是把 明文 (要传输的信息)进行一系列变换, 生成密文
解密就是把 密文 再进行一系列变换, 还原成明文
在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为密钥
HTTPS是如何进行加密的？
既然要保证数据安全, 就需要进行 "加密".
网络传输中不再直接传输明文了,而是加密之后的 "密文".
加密的放式有很多, 但是整体可以分成两大类: 对称加密 和 非对称加密
1.对称加密
加密和解密使用同一个密钥，加密和解密速度都比较快
由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道请求的真实内容是啥了.
但同一时刻服务器给很多客户端服务，并且每个客户端的密钥得不同，对于服务器来讲，要维护每个客户端和密钥的关系，这是一个很麻烦的事情。
比较理想的做法：让双方约定这次密钥是什么
但是如果直接把密钥明文传输, 那么黑客也就能获得密钥了~~ 此时后续的加密操作就形同虚设了.
这时候就得引入非对称加密了
2.非对称加密
密钥是一对：分别是公钥和私钥
公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多.
此时服务器会生成 ---> 公钥和私有
当客户端连上服务器的时候，服务器就会把自己的公钥告诉客户端，私钥还是服务器自己持
接下来客户端拿到公钥，会生成对称公钥（每个客户端会生成自己的对称公钥，客户端之间不知道对方的对称公钥是什么），进行明文加密发送服务器
假设此时黑客拿到了客户端发送的密文，也破解不了，因为使用公钥加密，就得拿到对应的私钥来进行解密，黑客可以拿到公钥，但拿不到私钥，私钥在服务器这边。
但还没完.....
中间人攻击：
此时黑客可以冒充服务器，在双方获取信息
黑客在客户端这边当做服务器 在服务器那边当做客户端 存在一个中间人的角色
此时服务器有自己的一套 公钥pub 和 私钥pri
黑客也有自己的一套 公钥pub2 和私钥pri2
当客户端向服务器获取公钥的时候，黑客向正在的服务器要公钥
当服务器发送给了客户端，就会被黑客拦截，黑客将自己生成的公钥pub2发送给客户端
然后客户端将公钥pub2生成的对称公钥进行加密，发送数据给服务器，此时半路被黑客拦截，并且使用自己的私钥pri2进行解密，获取到了客户端真正的明文，并且自己再根据公钥pub伪造一些数据发生给服务器
这样一来服务器会以为是客户端在正常通信，而客户端也以为是在和服务器通信，实际上双方的通信都被攻击者控制。
解法中间人攻击：
此时最重要的一点就是让客户端知道此时的公钥是不是服务器的；
引入第三方公证机构：
公证机构会对公钥进行“公证”，这样一来客户端看见了这个公钥被公证了，就可以认为它是合法的；证书就如身份证，证明服务端公钥的权威性
申请证书流程：
证书可以理解成是一个结构化的字符串, 里面包含了以下信息:
1）发证机构
2）证书的有效性
3）服务器的公钥
4）证书的所有者
5）持有者网站的主域名
6）数字签名
数字签名：针对前五项的内容进行校验和，再进行一下非对称加密
当客户端收到证书，就会对证书的合法性进行校验
- 判定证书的有效期是否过期
- 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).
- 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到⼀个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2.对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的.
