HTTPS 是什么
HTTPS 也是一个应用层协议。是在 HTTP 协议的基础上引入了一个加密层。 HTTP 协议内容都是按照文本的方式明文传输的，这就导致在传输过程中出现一些被篡改的情况。
至于HTTPS为啥能出现，就不得不提"运营商劫持"了。（这里就大概讲一下，想了解的可以搜一搜。） 比如我要下载一个QQ音乐，未被劫持的效果，就是点击下载按钮，就会弹出QQ音乐的下载链接，已被劫持的效果，点击下载按钮，就会弹出别的软件的下载链接。
由于我们通过网络传输的任何数据包都会经过运营商的网络设备（路由器，交换机等），那么运营商的网络设备就可以解析出你传输的数据内容，并进行篡改。
点击"下载按钮"，其实就是再给服务器发送了一个 HTTP 请求，获取到的 HTTP 响应其实就包含了该 APP 的下载链接，运营商劫持之后，就会发现这个请求是要下载QQ音乐，那么就自动的把交给用户的响应给篡改成别的软件的下载地址了。
其实不只是运营商可以劫持，其他的黑客也是可以用类似的手段进行劫持，来窃取用户隐私信息，或者篡改内容。
在互联网上**，明文传输是比较危险的事情！**
HTTPS 就是在 HTTP 的基础上进行了加密，进一步的来保证用户的信息安全。
HTTPS = HTTP + S（SSL / TLS）（SSL 也是一个应用层协议，专门负责加密）
"加密"是什么
加密就是把 明文 （要传输的信息）进行一系列变换，生成 密文。
解密就是把 密文 再进行一系列变换，还原成 明文。
在这个加密和解密的过程中，往往需要一个或者多个中间的数据，辅助进行这个过程，这样的数据称为 密钥。
加密解密到如今已经发展 成一个独立的学科：密码学。
而密码学的奠基人，也正是计算机科学的祖师爷之一，艾伦·麦席森·图灵。（感兴趣的可以去了解一下）
HTTPS的工作过程
要保证数据安全，就需要进行"加密"。
网络传输中不再直接进行明文传输了，而是加密之后的"密文"。
加密的方式有很多，但是整体可以分成两大类：对称加密 和 非对称加密。
对称加密
对称加密其实就是通过同一个"密钥"，把明文加密成密文，并且也能把密文解密成明文。
明文传输
引入对称加密
引入对称加密之后，即使数据被截获，由于黑客不知道密钥是啥，因此就无法进行解密，也就不知道请求的真实内容是啥了。
但是事情并没有说的那么简单，服务器同一时刻其实是给很多客户端提供服务的，这么多的客户端，每个人用的密钥都必须是不同的 （如果相同，那就意味着黑客自己搞个客户端就拿到密钥了），因此服务器就需要维护每个客户端和每个密钥之间的关联关系了，这也是个很麻烦的事情。
比较理想的做法是，在客户端和服务器建立连接的时候，双方协商确定这次的密钥是什么。
由于密钥本身是明文传输的，就很可能被黑客获取到，而一旦被黑客拿到密钥后，后续的加密操作就毫无意义了，**因此就需要对密钥进行加密，**如果任然使用对称加密的方式生成一个 key2 对称密钥，使用key2 对 key 进行加密，key 就可以进行密文传输给服务器了，但 key2 还是得传给服务器，难道搞一个 key3 对 key2 进行加密吗？此时我们发现，密钥的传输再用对称加密就行不通了。就需要引入 非对称加密。
非对称加密
非对称加密需要用到两个密钥，一个叫做"公钥"，一个叫做"私钥"。
公钥和私钥是配对的。最大的缺点就是 **运算速度非常慢，**比对称加密要慢很多。
- 通过公钥对明文加密，变成密文。
- 通过私钥对密文解密，变成明文。
也可以反着用
- 通过私钥对明文加密，变成密文。
- 通过公钥对密文解密，变成明文。
- 客⼾端在本地⽣成对称密钥, 通过公钥加密, 发送给服务器.
- 由于中间的⽹络设备没有私钥, 即使截获了数据, 也⽆法还原出内部的原⽂, 也就⽆法获取到对称密钥
- 服务器通过私钥解密, 还原出客⼾端发送的对称密钥. 并且使⽤这个对称密钥加密给客⼾端返回的响应数据.
- 后续客⼾端和服务器的通信都只⽤对称加密即可. 由于该密钥只有客⼾端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义
- 当前的场景有三个密钥
- 客户端生成的对称密钥
- 服务器生成的公钥，可以给所有设备告知
- 服务器生成的私钥，只有自己知道。
由于对称加密的效率比非对称加密高很多，因此只是在开始阶段协商密钥的时候使用非对称加密，后续的传输仍然使用对称加密。 对称加密：运算速度快，开销小，适合针对大量数据进行加密。 非对称加密：运算速度慢，开销大，加密小的数据还可以，加密大量数据，非常耗时。
但是上述这样的流程存在重大的安全隐患，黑客可以通过特殊手段，来获取到对称密钥，破环 后续传输的安全性。
中间人攻击
黑客可以通过中间人攻击来获得对称密钥。 那么这个中间人攻击是什么，就得举个例子了： 假如我是一名缉毒警察，再一次行动当作我抓住了一名毒枭，这个毒枭想要戴罪立功，减轻罪名，带我去了毒贩交易（A和B有一场毒品交易，但互相都不认识，想通过这个毒枭来完成交易），首先这个毒枭带着我先和A接头，让我假扮B，接头完之后，再让我假扮A和B接头，此时看似 A和B 完成了交易，但是这中间有内鬼。
因此，我们为了避免中间人攻击就需要引入校验机制，中间人攻击的关键，在于客户端无法区分收到的公钥是否是服务器真实的 公钥 还是被黑客篡改的公钥，我们就要想办法能够对公钥是否正确，进行校验~
引入证书
服务端在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息，公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。
-
客户端收到证书，就需要进行校验：
- 客户端需要针对证书中的其他字段（证书的颁布机构是谁，证书的有效期是什么时候，服务器的公钥是谁，服务器的拥有者（域名）是啥），使用同样的算法，再算一次校验和，得到了 校验和1（针对客户端收到的数据进行计算的）。
- 在通过公正机构的公钥 pub2 ，对数字签名进行解密，得到校验和2。（服务器申请证书的时候得到的原始校验和）
- 对比校验和1 和 校验和2 是否相同，如果相同。说明证书是没有修改过的。（没有内鬼，可以交易），如果不同，证书无效，中间被人篡改了（有内鬼，停止交易）。
-
那么在这块就有一个问题了，客户端如何确保拿到的 pub2 就是公正机构的 pub2而不是黑客伪造的 pub2呢？？
因为pub2就不是通过网络传输的，而是操作系统中内置的。（安装好系统，系统就内置 了一系列知名公正机构的公钥） 只要安装正版系统，不是黑客搞得盗版系统，就可以信任 pub2 是合法正确的。
如果黑客想要直接修改证书中的公钥为自己的公钥，此时就会导致客户端计算的校验和 和 解密出来的原始校验和就对不上了，此时客户端就会报错。浏览器就会弹出一个红色的网页，告诉你该网站不安全是否要继续访问。
黑客能否自己申请一个证书，用自己的证书，整个替换服务器的证书？
- 证书中包含服务器的域名，黑客申请的证书的域名和正经服务器的证书域名，肯定是不同的。
- 浏览器这边还是可以验证，输入的url的域名和得到的证书的域名是不是匹配，如果不匹配同样认为是证书非法。
- 浏览器就会弹出一个红色的页面，告诉你该网站不安全是否要继续访问。
- 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的
常见问题
为什么摘要内容在⽹络传输的时候⼀定要加密形成签名?
常⻅的摘要算法有: MD5 和 SHA 系列 以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点: • 定⻓: ⽆论多⻓的字符串, 计算出来的 MD5 值都是固定⻓度 (16字节版本或者32字节版本) • 分散: 源字符串只要改变⼀点点, 最终得到的 MD5 值都会差别很⼤. • 不可逆: 通过源字符串⽣成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的. 正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相同.
理解判定证书篡改的过程: (这个过程就好⽐判定这个⾝份证是不是伪造的⾝份证)
假设我们的证书只是⼀个简单的字符串 hello, 对这个字符串计算hash值(⽐如md5), 结果为 BC4B2A76B9719D91 如果 hello 中有任意的字符被篡改了, ⽐如变成了 hella, 那么计算的 md5 值就会变化很⼤. BDBD6F9CF51F2FD8 然后我们可以把这个字符串 hello 和 哈希值 BC4B2A76B9719D91 从服务器返回给客⼾端, 此时客⼾端 如何验证 hello 是否是被篡改过? 那么就只要计算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91 即可.
但是还有个问题, 如果⿊客把 hello 篡改了, 同时也把哈希值重新计算下, 客⼾端就分辨不出来了呀
所以被传输的哈希值不能传输明⽂, 需要传输密⽂.
所以，对证书明⽂(这⾥就是"hello")hash形成散列摘要，然后CA使⽤⾃⼰的私钥加密形成签名，将 hello和加密的签名合起来形成CA证书，颁发给服务端，当客⼾端请求的时候，就发送给客⼾端，中间⼈截获了，因为没有CA私钥，就⽆法更改或者整体掉包，就能安全的证明，证书的合法性。
最后，客⼾端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密, 还原出原始的哈希值, 再进 ⾏校验.
为什么签名不直接加密，⽽是要先hash形成摘要?
- 缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度
完整流程
左侧都是客⼾端做的事情, 右侧都是服务器做的事情
上述流程：
- 引入对称加密
- 引入非对称加密
- 中间人攻击
- 引入证书 & 数字签名
这些是 SSL 的握手流程，不只是局限于 HTTPS的其他基于 SSL 的网络协议，也是类似的过程。