Linux——https基础理论
1. 初步认识https协议
• 属于应用层
• 相较于http协议，https在应用层多了一层加密层，为了保证数据安全
• 简单理解：https就是对http的加密和解密
2. 中间人攻击
• 数据在传输过程中，遭第三方篡改。
3. 加密方式
• 对称加密：双方使用同一个密钥进行加密和解密
特点：通信速度快
• 非对称加密：需要两个密钥，一共公开 → 公钥， 一个私有 → 私钥
特点：慢
4. 加密方案
4.1 方案一：只使用对称加密
首次申请时，client端需要将对称密钥X，发给服务端，该过程会被中间人攻击，因此不安全，所以pass
4.2 方案二：只使用非对称加密
只能保证单向数据安全，所以pass
4.3 方案三：双方都使用非对称加密
通信的双方将各自的公钥传给对方，然后开始通信。
流程：
1. server端将公钥s传给client端
2. client端将公钥c传给server端
3. client端将数据+公钥s传给server端，server端用自己的私钥s对数据进行解密
4. server端拿着响应+公钥c传给client端，client 端用自己的私钥c对数据进行解密
缺陷：
1.本质还是不安全的，稍后解释
2.通信速度太慢了
4.4 方案四：非对称加密 + 对称加密
流程：
1. server端将公钥s传给client端，
2. client端将对称密钥X + 公钥s形成密文数据传给 server端
3. server端拿着自己的私钥s对密文数据进行解密，这样server端也就拿到了 对称密钥X，
4. 双方使用对称密钥x进行通信
缺陷：
中间人可以篡改由server端发送的公钥s，篡改为自己的公钥m，client端发送密文数据时， 发送的是：对称密钥X + 公钥m，中间人就可以拿自己的私钥m解密，获得对称密钥X
后续server端和client端通信时，中间人就一览无余了，这也是方案三的缺陷
注：
中间人为了隐藏其存在，将自己解出来的对称密钥X和原先的公钥S 进行加密，再传给server端，此时双方都不知道数据已经被中间人篡改过了
4.5 最终方案：非对称加密 + 对称加密 + 证书认证
现存方案问题：client端无法验证收到公钥s的合法性。
引入新概念：
• 摘要：将数据通过散列函数(哈希算法)得到的散列值称为摘要
• 签名：将获得的摘要通过签名者的私钥A进行加密，得到的数据称为签名
注：签名者是CA机构 or CA子机构，后续介绍
• 证书：铭文数据 + 签名的组合称为证书
• 验证：client端将 铭文数据通过散列函数得到的散列值H1，client端通过签名者的公钥A对签名进行解密，得到散列值H2，判断H1和H2是否相等来验证client端收到的公钥s是否合法。
方案五的通信流程：
1. server端拿着域名、公钥s、申请者向CA机构申请证书，
注：域名、公钥s、申请者等其他信息称为sever端的铭文数据
2. CA机构根据server端的铭文数据通过散列函数获得散列值，对散列值进行加密后获得签名，将铭文数据和签名数据附加在一起形成证书，然后再向server端颁发证书
3. 此时http服务器建立完毕，就可以正式上线给用户使用了
4. 用户端发起http申请，获得携带证书的公钥
5. 验证公钥的合法性，将 铭文数据通过散列函数得到的散列值 与 通过CA机构的公钥S解密后的散列值 进行对比，来验证合法性
注：所有的浏览器都内置了CA的公钥
6. 一旦公钥可信任，形成对称密钥X + 证书中的公钥s ，将对称密钥发给server端
注：如果有中间方修改了数据，用户进行验证时得到的散列值完全不同，该报文会被丢弃，只要中间方拿不到CA的私钥 or 用户使用的是合法的CA公钥进行解密，注定了中间方无法对信息进行篡改
7. 后续双方通过该对称密钥X进行通信。
补充：如何成为中间人？
假wifi or 假网站等