目录

一、为什么需要https 

二、常见加密方法

1、对称加密

2、非对称加密

3、数据指纹

 三、选择什么加密方案？

方案一：对称加密（×）

方案二：双方使用非对称加密（效率低）

方案三：非对称加密+对称加密

中间人攻击

四、引入证书

五、数字签名

六、终级方案：非对称加密 + 对称加密 + 证书认证

七、HTTPS一定是安全的吗？

---

一、为什么需要https 

HTTP协议内容都是明文传输的，传输过程可能会经过很多中间设备（如一个局域网中的路由器，电脑连接手机热点，公共产所的wifi等），这些中间设备可以抓取我们的请求或响应，会导致信息泄露，消息篡改等信息安全问题，因此有了HTTPS。

HTTPS协议也是一个应用层协议，是在HTTP协议的基础上引入了一个加密解密层：

二、常见加密方法

1、对称加密

加密和解密时使用相同的密钥。

特点：加密速度快，加密效率高 。

常见对称加密算法：DES、3DES、AES等

2、非对称加密

特点：解决密钥安全配送问题，但运行效率低。

通信双方各有一组密钥：公钥和私钥

公钥可公开，私钥必须保密，用公钥加密的密文必须用与该公钥配对的私钥解密。

接收方将自己的公钥公开给发送方。发送方使用接收方的公钥对数据进行加密，然后传输给接收方。即使在加密数据的过程中，接收方的私钥始终保密，因此无需对外公开。只有接收方拥有私钥可以解密数据。

常见非对称加密算法：RSA是使用最广泛的非对称密码算法。

3、数据指纹

对于一份明文数据，通过一种Hash算法（MD5），可以让其生成一个固定长度的，非常低概率发生冲突的固定长度的字符串（也叫数据摘要），具有唯一性，如果原文发生细微更改，生成的字符串都会有很大的不同，这就叫这份明文的数据指纹。

使用案例：

平时我们使用百度网盘的时候，可能会有看到秒传这样的现象，如何做到的呢？

假设有一个用户传了一部电影到百度网盘服务端，服务端会根据用诸如MD5这样的hash算法计算出它的摘要或者叫数据指纹，然后入库，当下一次另一个用户上传同样的一部电影时，经过计算发现其数据指纹对应的数据在服务端已经存在，就不需要再上层了，从而实现秒传。

 三、选择什么加密方案？

方案一：对称加密（×）

客户端和服务端双方约定好同一个密钥，但这并不靠谱。

1. 密钥分发困难：对称加密需要双方共享相同的密钥，如果密钥在传输过程中被攻击者截获，会导致加密效果失效。在服务端和客户端之间安全地传输密钥是一项挑战。

2. 密钥管理成本高：当客户端数量庞大时，需要为每个客户端分配一个唯一的密钥，密钥管理成本将大大增加。

方案二：双方使用非对称加密（效率低）

由于非对称密钥算法效率比对称密钥算法的效率低，所以我们还行再改进一下。

依旧有安全问题

方案三：非对称加密+对称加密

服务端具有公钥S和私钥S'

客户端发起请求获取服务端公钥S；

客户端形成一个对称密钥C，将C通过服务器端的公钥进行加密发送给服务器。服务器通过私钥S’进行解密获得对称密钥C。

之后双方就采用对称加密，这样只有传送对称密钥C时采用的是非对称密钥，其他时候都采用的是对称密钥，因此可以大大提高效率。

接近最佳方案，但依旧有安全问题

中间人攻击

上面的方案都有一个安全问题：如果在一开始就受到中间人攻击了呢？

1. 服务器具有非对称加密算法的公钥S，私钥S'
 2. 中间人具有非对称加密算法的公钥M，私钥M" 3. 客户端向服务器发起请求，服务器明文传送公钥S给客户端。
 4. 中间人劫持数据报文，提取公钥S并保存好，然后将被劫持报文中的公钥S替换成为自己的公钥M，并将伪造报文发给客户端。
5. 客户端收到报文，提取公钥M(自己当然不知道公钥被更换过了),自己形成对称秘钥X，用公钥M加密X，形成报文发送给服务器。

6. 中间人劫持后，直接用自己的私钥M'进行解密，得到通信秘钥X，再用曾经保存的服务端公钥S加密后，将报文推送给服务器。

7.服务器拿到报文，用自己的私钥S'解密，得到通信秘钥X 8. 双方开始采用$X$进行对称加密，进行通信。但是一切都在中间人的掌握中，劫持数据，进行窃听甚至修改，都是可以的

根本原因：客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的。

四、引入证书

服务端在使用HTTPS前，需要向CA机构领取一份数字证书，数字证书里含有申请者信息，公钥信息等。服务器将证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明服务端公钥的权威性。

怎么保证证书是真的，且没有被篡改过？看下面：

五、数字签名

签名：用签名者的私钥对数据摘要进行加密，就形成了一个签名，将加密后的数据摘要附加到原始数据上就形成了带有数据签名的数据，并将他们一同发送给接收方。

验证： 接收方收到两部分内容：数据摘要和原文；要对签名进行验证，首先要签名者的公钥解密得到数据摘要，再根据原文用相同的算法计算出数据摘要，比较俩个值，如果相同，则数字签名有效。

CA机构就是通过数字签名技术来帮助辨别CA证书的真伪。

六、终级方案：非对称加密 + 对称加密 + 证书认证

前面提到几种方案都有安全隐患即：客户端无法确定收到的含有公钥的数据报文，就是目标服务器发送过来的。

那么这个方案就可以解决这个问题：

客户端发起第一次请求时，服务端要将自己的CA证书（包括CA机构的认证签名，服务端的

公钥、域名等信息）响应给客户端。客户端收到证书后，用其内置的很多权威CA机构的公钥来验证签名（用公钥对数据摘要解密，再与计算根据明文计算出来的数据摘要进行比对），比对成功，则证明证书是可信的，也就是说证书上的服务端的公钥是可信的，由此就可以防范中间人攻击。之后客户端就可以用服务端的公钥来加密自己的对称密钥R，发送给服务端后，双方就可以通过对称密钥来进行通信。

中间人有没有可能篡改该证书？

1）篡改明文？篡改明文后客户端验证签名时会比对失败

2）掉包整个证书？中间人没有私钥，所以无法制作假证书，只能用真证书来掉包，但证书里面是有域名等信息的，客户端可以识别出来域名发生了变化。

 为什么签名不直接加密，而是要先hash形成摘要？

1）缩小签名密文长度，加快数字签名的签名和验证效率。

七、HTTPS一定是安全的吗？

不一定。

上面提到的中间人攻击本质是对客户端进行攻击，那如果客户端本身就是攻击者呢？