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

证书存在的意义是 保证内容没有被篡改，在验证 证书合法性的同时 也验证了公钥的合法性