前言

假设客户端给服务器发送HTTP请求,此时的数据都是明文的,如果黑客在这个过程中截取到了数据,进行篡改是非常容易的,这样就会造成严重后果.

HTTPS和HTTP一样,都是应用层协议.只不过HTTPS在HTTP的基础上又加了一个加密层,保证传输数据的安全性.

下面我们就来探讨一下HTTPS是如何进行加密的.

一.对称秘钥

key

是双方通过同一个key,进行加密和解密. 客户端给服务器发送用key加密后的密文,服务器使用key进行解密。

一个服务器可以连接多个客户端,每个客户端的key都是不同的.如果服务器储存这么多不同key的信息，管理起来会很麻烦。于是在传密文前先约定key，也就是在客户端和服务器建立连接时发送key。

接下来，客户端就能发送加密后的密文了。
但是，发送的key仍然是明文的，黑客一旦窃取到，后续就能在客户端发送用key加密的密文时，使用key进行解密。

所以，我们怎么保证key安全呢？
在约定key时，对key进行加密，这样就算黑客拿到加密后的key，也无法解密，也就拿不到key.

二.非对称密钥

pub和pri

一对公钥（pub）和私钥（pri）.一个加密，另一个就可以解密。可以互换身份，但是私钥绝对不可以泄露出去

保证key的安全，就可以使用非对称密钥。

1.客户端向服务器索要服务器的公钥pub，服务器向客户端发送pub
2.客户端向服务器发送用pub加密后的key。服务器再使用私钥pri进行解密。拿到key之后，回复ok。建立连接成功
后续客户端就能发送用key加密的密文了。

但是，上述过程并非安全，黑客可以拿到pub，也就可以篡改pub(偷梁换柱）。自己生成一组非对称密钥pub1和pri1，将服务器的pub替换成自己的pub1，客户端用pub1对key进行加密后，黑客使用pir1进行解密，拿到key值。接下来，又用服务器的pub对key进行加密，服务器使用pri解密成功。没有发现异常。
此时的黑客就神不知鬼不觉的拿到key了。

那我们如何解决这个问题呢？关键在于保证客户端拿到的pub一定是正确的属于服务器的pub。
所以我们需要把服务器的pub给存储起来。此时，就可以使用证书了。

三.证书

在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书.这个证书包含了服务器的公钥, 也包含了网站的身份信息。（类似于我们的身份证）

校验和

在服务器给客户单返回证书之前，先将证书中的所有属性计算一遍，得到校验和sum1，证书自己拥有一对、组非对称密钥（pub2和pri2）。通过pri2对sum1进行加密。得到签名，放入证书中，一起返回给客户端。

当客户端收到证书时，会对这个证书中的属性进行验证，以防白被篡改。
1.客户端使用pub2将签名进行解密，得到sum1；
（pub2是绝对正确的，是系统自动分配给 客户端的）
2.客户端重新计算一遍校验和，得到sum2；
3.客户端比较sum1和sum2，如果不同，则被修改了。

那么如果黑客修改了校验和呢？因为黑客也可以拿到pub2，幼也可以拿到sum1。
这是不可以的。因为黑客拿不到私钥pri2，无法对修改后的新校验和进行加密。

双重保障

在证书中，黑客有两种手段，但都无法实现。

• 修改证书中的服务器公钥pub
  这样在比较校验和时，会发现sum1≠sum2。
• 修改证书中的服务器公钥pub以及签名
  无法修改签名。黑客解密签名，拿到校验和sum1，按照修改后的属性重新计算一遍得到新校验和，也无法对其进行加密。（没有证书私钥pri2）

总结

上述加密过程涉及到了三组密钥：

• 一组非对称密钥：证书的公钥pub2和密钥pri2；
• 一组非对称密钥：服务器的公钥pub和密钥pri；
  一组对称密钥：客户端的对称密钥key。

HTTPS的工作流程大致如下：
1.在客户端和服务器建立连接时，客户端向服务器找索要证书，拿到证书后使用证书公钥pub2对签名进行解密，检验校验和是否一致；
2.验证成功后，客户端使用拿到的服务器pub对key进行加密，发送给服务器，服务器收到后使用pri对加密后的key进行解密，拿到key；
3.确保服务器拿到key后，客户端使用key对要传输的数据进行加密，发送给服务器，服务器收到后，使用key进行解密，拿到数据。