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进行通信。