HTTPS加密过程详解

HTTPS协议

HTTPS协议也是应用层的一种网络协议，与HTPP协议报文格式都一样，仅在HTTP协议的基础上，引入了加密层。由于HTTP协议内容的明文传输，导致其传输过程十分不安全，所以加密的HTTPS可以简单理解为HTTP的安全版。

明文传输时非常不安全的操作，可能会面临运营商劫持篡改信息以及黑客劫持窃取用户隐私等隐患。HTTPS就是在HTTP的基础上进行了加密操作，进一步保障用户信息的安全性。

加密的相关概念

• 明文：原始的传输内容；
• 密文：经过一定规则变换之后的传输内容；
• 加密：将明文转换为密文的过程；
• 解密：将密文转换为明文的过程；
• 密钥：在加密或解密过程中使用的某些数据，用于辅助该过程。

HTTPS工作过程

对称加密

对原始的传输数据进行加密，而加密和解密过程使用的是同一个密钥。
举个例子进行说明。最简单的对称加密就是按位异或，
假设，明文 a = 1234，密钥 key = 8888，
则加密 a ^ key 得到密文 b = 9834。
那么解密时也是用 b ^ key 得到原本的明文 a = 1234。

此处的按位异或仅作示例，实际的HTTPS加密解密的运算过程时十分复杂的，但原理与上述类似。

优势：如下图所示，使用对称加密后，即使黑客入侵拿到了请求内容，也不知道密钥是什么，自然无法解密，那么他拿到的数据就没有任何意义。而客户端和服务器都知晓密钥，客户端使用密钥加密，服务器使用密钥解密，由此保证了安全性。

缺陷：上述的方案看似可以实现数据的安全传输，但有一个前提条件，就是客户端与服务器如何进行密钥的统一约定？

由于一个服务器对应多个客户端，每个客户端都需要和服务器有其特定的密钥，而且每个客户端的密钥都是不同的（若时相同的密钥安全性也太低了），若是这么多的密钥都由服务器管理未免负载过大，所以最好的方案是客户端生成密钥，然后把这个密钥告诉服务器，服务器保存这个密钥。
此时在服务器中以类似哈希表的方式存储这个密钥（key：客户端id ， value：对应的密钥）。

但是在客户端将密钥告诉服务器的这个过程是通过网络通信的，那么就很有可能被黑客拦截到。如下图所示，当客户端告诉服务器密钥是888888的时候，黑客就已经拦截了传输数据并且获取到了密钥是888888，那么此后的各种加密解密过程，黑客可以使用手中的密钥进行解密，如此一来，后续的任何操作都毫无意义了。

至此，我们可以看到，对称加密并不安全，虽然可以使传输的数据被加密，但是密钥存在泄露的可能性。

非对称加密

为了弥补对称加密的不安全性，保证密钥不泄露，就需要对密钥进行加密，但如果对密钥使用对称加密，相当于套了一层娃，还是会发生密钥的密钥泄露的情况。所以此时使用非对称加密方式对密钥进行处理。

非对称加密需要使用一对密钥，一个公钥，一个私钥；公钥用来加密，私钥用来解密。
交互过程如下图所示：

1. 服务器生成一对公钥和私钥，公钥公开出去，任何人都能拿到公钥，包括黑客，而私钥只有服务器自己有。
2. 客户端拿到公钥后，使用公钥对对称密钥进行加密，将加密后的密钥密文通过网络传输给服务器。
3. 黑客也可以拦截到客户端发出的密文请求，但黑客只有公钥，没有私钥，无法对密文解密，此时密文请求就安全的传输给了服务器。
4. 服务器拿到密文请求后，通过私钥对密文进行解密，得到对称密钥。
5. 黑客没有私钥，无法解密客户端发出的密文请求，也就无法得到对称密钥，那么后续客户端和服务器就可以安全的使用对称密钥进行加密解密了。

非对称加密明显更安全，为什么还要使用对称密钥？

因为对称加密的成本是远远小于非对称加密的，而实际开发中客户端和服务器之间传输的数据量是非常大的，如果全部使用非对称加密，那么整体的速度会非常慢，所以仅使用非对称加密来加密对称密钥，这样不仅提高了安全性，也保证了运行效率。

中间人攻击

非对称加密看似已经足够安全，但狡猾的黑客又想出了一出“狸猫换太子”，称为中间人攻击。交互过程如下图所示：

1. 服务器生成一对公钥public1和私钥private1，自己持有私钥，将公钥公开出去。
2. 客户端通过网络获取服务器的公钥。而黑客也可以自己生成一堆非对称密钥public2 和 private2，黑客将服务器公开的public1记下来，然后返回给服务器自己生成的公钥public2（模仿服务器来骗客户端）。
3. 客户端拿到假的公钥public2后，使用public2对称密钥888888进行加密。
4. 客户端将密文请求发给服务器时，黑客拦截此请求，并根据自己的私钥private2对客户端的密文请求进行解密，由此得到了对称密钥888888。
5. 为了防止被发现自己在中间搞鬼，黑客b把对称密钥888888通过之前记住的正确的公钥public1重新加密，再继续发送给服务器（模仿客户端来骗服务器）。
6. 服务器拿到该密文请求后，使用自己持有的私钥private1进行解密，得到了888888的对称密钥。
7. 由此，客户端与服务器之间沟通密钥的过程已经完成，后续将按照888888的对称密钥进行交互。但遗憾的是，黑客作为中间人的身份，伪造双方的请求，已经知晓了对称密钥，所以后续数据传输的加密也形同虚设。

分析整个过程，我们可以发现，出现中间人攻击这种隐患的根本原因是由于客户端需要通过网络获取到服务器的公钥，但是客户端无法识别这个公钥是否是伪造的，所以才会出现黑客伪造的情况。

引入证书机制

为了避免出现中间人攻击的隐患，就需要想办法让客户端能够识别其获取到的公钥是服务器发布的正版公钥，还是黑客伪造的虚假公钥，此时就需要引入第三方的公证机构。
其交互过程如下图所示：

• 注意：证书 = 公钥 + 身份标识；
  

1. 服务器向第三方机构申请一个证书，申请成功会返回包含公钥和身份标识的证书。由于第三方机构要求申请者提供各种资质，还要审核，所以黑客会断然申请不到证书的。
2. 服务器公开申请的证书，所有人都能拿到，此时黑客拿到证书后无法篡改其中的公钥，因为一旦篡改后返回给客户端，客户端按着篡改后的证书去第三方验证，会返回不合法的结果，一下子就识别出黑客改了公钥。
3. 客户端拿到服务器返回的证书后，去第三方机构验证该证书是否合法，若是合法的，则证书中的公钥就是正确的。