HTTPS

目录

1.对称加密

2.非对称加密

中间人攻击

解决

---

        HTTPS 也是一个应用层协议，是在 HTTP 协议的基础上引入了一个加密层。为了实现安全传输，核心就是加密。

1.对称加密

        加密时，明文+key=密文，解密时，密文+key=明文，此处的key（密钥）是相同的，这就是对称加密。此处的key可以认为是一串数字或字符串，通过密钥和明文进行一系列数学运算就是密文。

        但是服务器同一时刻要给很多客户端服务，如果每个客户端的密钥都相同，那就很容易被中间网络设备识别，因此每个客户端都要有不同的密钥，如此一来服务器就要维护每个客户端和密钥的关联关系。

        假设由客户端生成一个密钥，然后把密钥告诉服务器，但这个密钥只能明文传输，就有可能被中间网络设备截获。要上解决安全的把密钥传给服务器就引入了非对称加密。

---

2.非对称加密

        生成一对密钥，公钥和私钥，使用公钥加密，明文+公钥=密文，使用私钥解密，密文+私钥=明文，反过来也行，这就是非对称加密。

        开始阶段协商密钥时，通过将对称密钥进行非对称加密，服务器生成一对公钥私钥，客户端向客户端请求公钥，服务器持有私钥，中间网络设备可以知道公钥，但私钥是服务器私有的；客户端使用公钥，来对对称密钥加密，传输给服务器，服务器用私钥解密得到对称密钥，一旦对称密钥到达服务器，后续的传输都使用对称密钥加密，在这个过程中由于对称密钥使用公钥加密，所以中间网络设备无法解密出对称密钥，就不会被截获。

        此处为什么还要保留对称加密，不全部使用非对称加密？

因为对称加密较非对称加密快，效率高。

---

中间人攻击

        但是这个过程并不是天衣无缝，还存在中间人攻击。 

        当客户端向服务器请求公钥时，并不能保证公钥不是中间设备伪造的，如果中间设备生成一对非对称密钥，将伪造的公钥发给客户端，此时客户端生成对称密钥key，并使用伪造的公钥对key加密，客户端将加密好的对称密钥发送给中间设备，中间设备再根据自己的私钥解密，这样就得到了对称密钥key，之后中间设备就可以使用服务器的公钥对key加密，并发给服务器，此时服务器就以为这个对称密钥是客户端发来的，后续交互就直接使用对称密钥进行。

解决

        解决中间人攻击的关键，在于客户端能辨别这个公钥是来自与服务器，而不是直接设备的，这里的做法是引入一个“证书”，服务器的公钥包含于这个证书中。

        客户端向服务器请求公钥时，会请求整个“证书”，拿到证书后，会对证书进行校验，如果证书是无效的，会直接弹框警告。

       这个校验过程为客户端使用认证机构提高的公钥来解密证书中的“签名”（被加密的字符串）字段，得到结果1（相当于一个hash值），根据同样的hash算法，对其他字段再算一次hash值，判断两次hash值是否相同。

        黑客无法篡改证书。一旦替换公钥，客户端计算出的两次hash值就对不上，并且，黑客也无法知道认证机构的私钥，即使算好了篡改后的hash值，也无法加密生成签名，因为认证机构有一组公钥私钥，私钥加密hash值得到签名，公钥是客户端解密签名获取hash值的。

以上就是本文的全部内容了。