1. HTTPS的概念
HTTPS也是一个应用层协议，在HTTP协议基础上引入加密层
由于HTTP协议内容都是按照文本形式 明文传输的，就导致在传输过程中出现一些篡改的情况
报文在传送时，有效载荷是明文传送的，容易泄露 在应用层和传输层之间 添加 软件层 ，一般称为 SSL /TLS
SSL/TLS 本质就是 HTTP的握手协商、加密解密
所以此时的数据交给 传输层的都是经过加密的
远端主机也是要进行通信的 转而将数据交给远端的HTTP 通过加一层软件层，就可以在协议栈中添加 加密 解密 功能 网络中的实际报文 一定是被加密的
HTTP 加上 SSL/TLS 称之为 HTTPS
2. 加密
加密就是把明文 进行一系列转换 生成为密文 解密 就是把 密文再进行一系列变换，还原成明文
在这个加密和解密的过程中，需要一个或者多个中间的数据，辅助进行这个过程，这样的数据称为密钥
常见的加密方式
对称加密
采用 单钥 密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密 也称为 单秘钥加密，特征：加密和解密所用的密钥是相同的 特点：算法公开、计算量小、加密速度快、加密效率高
非对称加密
用两个密钥来进行加密和解密，这两个密钥是公开密钥和私有密钥
公钥：可以向全网公开 私钥：只能自己拥有
用公钥加密，只能用私钥解密 用私钥加密，只能用公钥解密
因为公钥是公开的，所以所有人都可以使用公钥来进行 加密和解密
特点：算法强度复杂 ，安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快
3. HTTPS的工作过程的探究
方案1 —— 只使用对称加密
若通信双方都各自持有同一个密钥，并且没有别人知道，这两方的通信安全当然是可以保证的 (除非密钥被破解)
即使黑客将数据截获，但是由于黑客并不知道密钥是啥，所以就没办法解密，也就不知道请求中的内容
如何保证客户端和服务端双方用同一个密钥？ 若内置，则内置到windows操作系统还是浏览器中，无论是哪一个，则黑客都有一定渠道获取到
若刚开始时将密钥传给服务器，服务器就知道了对应的密钥了，双方再用密钥做加密 但 将密钥 经过客户端发送给服务器 ，无法保证密钥本身的安全 所以该方案是不安全的
方案2 —— 只使用 非对称加密
当使用公钥 加密， 使用私钥解密时，就算让黑客将数据截获，也没有关系，因为只有私钥才能解密 似乎看起来是安全的
(私钥加密 ，公钥解密) 若服务器用它的私钥数据 加密 传给浏览器，浏览器就可以用公钥解密它，公钥被全网公开 若这个公钥 被人劫持了，则他也能用该公钥 解密 服务器传来的消息 所以该方案也是不安全的
方案3 —— 双方都是用非对称加密
服务器拥有公钥S和私钥S1，客户端拥有公钥C和公钥C1 客户端和服务器在通信之前，交换下自己的公钥 客户端把自己的公钥 直接发给服务器，服务器就知道了客户端的公钥C 服务器再把自己的公钥 直接发给客户端，客户端就知道了服务器的公钥S
若客户端给服务器发消息，用公钥S加密，只有服务器能解密
若服务器给客户端发消息，则用公钥C进行加密
这种做法看似是安全的，但是存在效率低下的问题(非对称加密速度比较慢，而且双方都使用非对称加密就更慢了) 但依旧有安全的问题
方案4 —— 非对称加密 对称加密
服务器采用非对加密解密，客户端采用对称加密解密 服务器拥有公钥S和私钥S1 客户端发起HTTP请求，服务器 在响应 请求和响应都是明文的 服务器响应时，给客户端推送服务器端的公钥S
假设客户端形成对称秘钥C 通过 对称秘钥C和 推送公钥S 形成 一段密文 将加密后的数据推送给服务器端
服务器端再用自己的私钥S1 进行解密，形成对称密钥C 通过对称秘钥C来完成对称加密，保证双方数据的数据安全 但依旧有安全问题
中间人攻击
以方案四为例 简称 MITM 攻击
客户端获取到公钥S后， 客户端形成对称秘钥C 用服务器端给客户端的公钥S加密 中间人即使 窃取数据，中间人确实 无法解出 客户端形成的密匙C
M表示中间人 服务器端 具有 非对称加密的公钥S和私钥S1 中间人 具有 公钥M和私钥M1
客户端先请求，然后服务器响应，服务器向客户端发送公钥S
当服务器把自己的公钥推送给客户端时，中间人截获 将 S从报文中 拿出来保存好，并将中间人自己的公钥M填进去
将新的报文转发给客户端，因为客户端请求的服务器端，所以就默认是服务器端发送的报文 客户端得到公钥M，客户端并不知道公钥被更换过
客户端就正常运行，公钥M与客户端形成的对称秘钥X 结合成 加密报文 并将加密报文推送给中间人，此时就可使中间人对应的私钥M1 对加密报文解密 使中间人获得客户端的对称秘钥X
获取到客户端的对称秘钥X后，在与服务器的公钥S结合，重新形成 新的加密报文 再将新的加密报文 推送给服务器 服务器 只觉得给 客户端 推送公钥S，就应该返回 带有公钥S的加密报文 服务器依然进行解密，也获得了客户端的 对称秘钥 X
总结： 中间人攻击，核心原因是什么？ 客户端无法验证公钥的合法性
引入证书
给别人提供网络服务的服务端，本身是否为合法的，并不由它自己说了算， 要引入一张权威的、第三方的机构来对服务端做认证
如：你是一个餐厅的老板，餐厅做的菜是否符合食品安全，你是不知道，就算你说好的，别人凭什么相信你 所以必须去政府的相关单位，获得经营许可证，获得了该证，食品安全就有了一点保证 所以此时别人相信该餐厅的食品安全，是因为相信给这个餐厅认证的食品安全部门
CA认证
CA机构是 互联网标准化组织，以及整个网络标准化组织 共同筹建的 机构 对全国范围内所有对应的 服务器进行认证，颁发一个电子证书后，服务器才能被信任
要想使用 HTTPS，就必须在CA机构中认证，以获取到CA证书 若不认证，则 浏览器会弹窗，链接是不安全的，导致客户不相信该网站
数字证书本质就是数据
理解数据签名
对大文本进行摘要，再对摘要的信息进行加密 即 数据签名
将文本经过哈希散列，形成散列值 用 特定CA证书 的私钥 对 散列值进行加密 形成 签名
将原始的文本和签名 结合，形成签名的数据 这个过程称为 颁发一个证书
将证书推送给某一个人时，将收到的证书(明文) 拆分为 数据 和对应的签名 对原始的数据 继续使用 哈希散列 形成散列值 再对加密过的签名，使用CA证书的公钥 解密 形成 散列值
对比两者的散列值 是否相等 若相等，则说明签名数据没有被篡改过 若不相等，则 明文数据和签名数据至少有一个被篡改过
方案5 —— 非对称加密 对称加密 证书认证
客户端先请求，然后服务器响应，给客户端证书
1. 验证证书的合法性
客户端先认证，证书的合法性
通过验证，将内容和签名 分开，用相同的hash算法，形成对应的散列值 先将数据 使用 hash算法，形成对应的散列值 使用浏览器内置公钥，对签名做解密，形成散列值
若两者的散列值 不同，有可能 数据被篡改了，所以直接丢弃 若两者的散列值相同，说明内容没有被篡改以及证书是合法的
2. 客户端在证书中提取公钥
若证书是合法的，则提取证书中的公钥
客户端在形成对称秘钥X，与提取出的公钥 结合，形成加密报文 将加密报文推送给 服务器，服务器通过对应的证书私钥解密 就形成了 客户端的对称秘钥X
证书存在的意义是 保证内容没有被篡改，在验证 证书合法性的同时 也验证了公钥的合法性
