目录
- 数据加密
- 常见的加密方式
- 数据摘要
- 方案一：仅使用对称加密
- 方案二：仅使用非对称加密
- 方案三：双方都使用非对称加密
- 方案四：非对称加密 + 对称加密
- CA认证证书
- 方案五：非对称加密 + 对称加密 + 证书认证
- HTTPS完整流程
数据加密
HTTPS 也是一个应用层协议，是在 HTTP 协议的基础上引入了一个加密层。因为 HTTP 的内容是明文传输的，明文数据会经过路由器、wifi 热点、通信服务运营商、代理服务器等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击 ，所以我们才需要对信息进行加密。
加密就是把明文进行一系列变换生成密文，解密就是把密文再进行一系列变换还原成明文。在加密和解密的过程中，往往需要一个或多个中间数据辅助这个过程，这样的数据称为密钥。
常见的加密方式
-
对称加密
- 采用单钥密码系统的加密；
- 加密和解密所用的密钥是相同的；
- 计算量小，因此加密速度快。
-
非对称加密
- 需要两个密钥来进行加密和解密，公开密钥和私有密钥；
- 算法强度复杂，因此加密速度较慢；
- 通过公钥对明文加密，变成密文，私钥对密文解密，变成明文，当然也可以反着用；
- 用公钥加密，只有私钥能解密，反着来同样的也只有持有私钥的人才能加密。
数据摘要
数据摘要的基本原理是利用单向散列函数对信息进行运算，生成一串固定长度的数字摘要。和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常用来进行数据对比，因此可以用来判断数据有没有被篡改。
方案一：仅使用对称加密
对数据进行对称加密可以让中间人不能得到真实数据，保证信息安全。但服务器要给很多客户端提供服务，这么多客户端每个人用的秘钥都必须是不同的，因此服务器就需要维护每个客户端和密钥之间的关联关系，比较麻烦。
有个办法就是让客户端和服务器在建立连接的时候，双方协商确定这次通信的密钥。但是如果直接把密钥明文传输，那中间人也就能获得密钥了，因此密钥的传输也必须加密传输。那么这就形成死循环了。
方案二：仅使用非对称加密
如果服务器先把公钥以明文方式传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，因为只有服务器有相应的私钥能解开公钥加密的数据，所以从客户端到服务器信道暂时是安全的。
但是如果服务器用它的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，若这个公钥被中间人劫持到了，那他也能用该公钥解密服务器传来的信息了。
方案三：双方都使用非对称加密
- 服务端拥有公钥 S 与对应的私钥 S’，客户端拥有公钥 C 与对应的私钥 C’；
- 客户和服务端交换公钥；
- 客户端给服务端发信息前先用 S 对数据加密再发送，只能由服务器解密，因为
只有服务器有私钥 S’； - 服务端给客户端发信息前先用 C 对数据加密再发送，只能由客户端解密，因为
只有客户端有私钥 C’ ；
这个方案好像可行，但是有两个问题：
- 非对称加密效率太低
- 依旧有安全问题
如何提高效率呢？
方案四：非对称加密 + 对称加密
- 服务端拥有非对称公钥 S 和私钥 S’；
- 客户端发起 https 请求，获取服务端公钥 S；
- 客户端在本地生成对称密钥 C，用公钥 S 加密，发送给服务器；
- 由于中间人没有服务端私钥，即使截获了数据也无法还原出内部的原文；
- 服务端通过私钥 S’解密，还原出客户端发送的对称密钥 C，并且使用这个对称密钥加密给客户端返回的响应数据；
- 后续客户端和服务器的通信都只用对称加密即可。
这样只在开始阶段协商密钥的时候使用非对称加密，后续的传输都使用对称加密，效率就提高了。
但是这种方案只提高了效率，还没有解决安全问题，什么安全问题呢？
如果中间人在最开始握手协商的时候就开始攻击了，可能会发生下面的问题：
- 服务器拥有非对称加密算法的公钥 S，私钥 S’；
- 中间人拥有非对称加密算法的公钥 M，私钥 M’；
- 客户端向服务端发起请求，服务端明文传送公钥 S 给客户端；
- 中间人劫持数据报文，提取公钥 S 并保存，然后将被劫持报文中的公钥 S 替换
成为自己的公钥 M，并将伪造报文发给客户端； - 客户端收到报文，提取公钥 M，自己形成对称秘钥 X，用公钥 M 加密 X，形成报文发送给服务器；
- 中间人劫持后，直接用自己的私钥 M’进行解密，得到通信秘钥 X，再用曾经保存
的服务端公钥 S 加密后，将报文推送给服务器； - 服务器拿到报文，用自己的私钥 S’解密，得到通信秘钥 X；
- 双方开始采用 X 进行对称加密通信，但是他们不知道的是他们的通信信息中间人也能看到，甚至修改。
那么这个问题的痛点在哪里呢？
客户端无法确定收到的含有公钥的数据报文，是不是真的由目标服务器发送过来的。
CA认证证书
服务端在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥，证书就如身份证，证明服务端公钥的权威性。
当服务端申请 CA 证书的时候，CA 机构会对该服务端进行审核，并专门为该网站形成
数字签名，过程如下：
- CA 机构拥有非对称加密的私钥 A 和公钥 A’；
- CA 机构对服务端申请的证书明文数据进行 hash，形成数据摘要；
- 然后对数据摘要用 CA 私钥 A’加密，得到数字签名 S；
- 服务端申请的证书明文和数字签名 S 共同组成了数字证书，这样一份数字证书就可以颁发给服务端了。
方案五：非对称加密 + 对称加密 + 证书认证
客户端和服务端建立连接，服务器给客户端返回一个证书，证书中有服务端的公钥，还有网站的身份信息。
客户端系统中已内置了受信任的证书发布机构，当客户端获取到这个证书之后，会对证书进行校验，判定证书是否过期、证书的发布机构是否受信任、证书是否被篡改等等。
然后从系统中拿到该证书发布机构的公钥，对签名解密，得到一个 hash 值(数据摘要)，设为 hash1，然后计算整个证书的 hash 值，设为 hash2，对比 hash1 和 hash2 是否相等，如果相等则说明证书是没有被篡改过的。
| 如果中间人篡改了证书的明文？
由于他没有 CA 机构的私钥，所以无法 hash 之后用私钥加密形成签名，那么也就
没法办法对篡改后的证书形成匹配的签名。
| 如果强行篡改？
客户端收到该证书后会发现明文和签名解密后的值不一致，则客户端就能知道证书已被篡改，从而终止向服务器传输信息。
| 中间人整个掉包证书？
因为中间人没有 CA 私钥，所以无法制作假的证书，除非他向 CA 申请真证书（但估计没有🤡会这么干），然后用自己申请的证书进行掉包。
中间人没有 CA 私钥，所以对任何证书都无法进行合法修改，包括自己的。
| 为什么数据在网络传输的时候一定要加密形成签名?
常见的摘要算法 MD5 有以下特点:
- 定长：无论多长的字符串，计算出来的 MD5 值都是固定长度；
- 分散：源字符串只要改变一点点，最终得到的 MD5 值都会差别很大；
- 不可逆：通过源字符串生成 MD5 很容易，但是通过 MD5 还原成原串理论上不可能。
因此我们可以认为如果两个字符串的 MD5 值相同，则这两个字符串相同。
假设我们的证书只是一个简单的字符串 happy，对 happy 计算 hash 值结果为BC4B2A76B9719D91。如果 happy 中有任意的字符被篡改，那么计算的 md5 值就会变化很大，比如：BDBD6F9CF51F2FD8。
然后我们可以把这个字符串 happy 和哈希值 BC4B2A76B9719D91 从服务器返回给客户端，此时客户端只需要计算 happy 的哈希值判断是不是 BC4B2A76B9719D91 即可。
| 如果中间人把 happy 篡改，同时也把哈希值重新计算下，客户端该如何应对？
所以被传输的哈希值不能传输明文，只能传输密文。所以对证书明文 hash 形成散列摘要，然后 CA 使用自己的私钥加密形成签名，将 happy 和加密的签名合起来形成CA 证书颁发给服务端，即使中间人截获了，因为没有 CA 私钥，就无法更改或者整体掉包，就能安全的证明证书的合法性。
最后，客户端通过操作系统里已经存好的证书发布机构的公钥进行解密，还原出原始的哈希值，再进行校验。
HTTPS完整流程
HTTPS 工作过程中涉及到的密钥有以下三组。
-
第一组（非对称加密）：用于校验证书是否被篡改。服务器持有私钥（私钥在形成 CSR 文件与申请证书时获得），客户端持有公钥（操作系统包含了可信任的 CA 认证机构），服务器在客户端请求时，返回携带签名的证书，客户端通过公钥进行证书验证，保证证书的合法性，进一步保证证书中携带的服务端公钥权威性；
-
第二组（非对称加密）：用于协商生成对称加密的密钥。客户端用收到的 CA 证书中的服务端公钥给随机生成的对称加密的密钥加密，传输给服务器，服务器通过私钥解密获取到对称加密密钥；
-
第三组（对称加密）：客户端和服务器后续传输的数据都通过这个对称密钥加密解密。一切的关键都是围绕这个对称加密的密钥，其他的机制都是辅助这个密钥工作的。第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器，第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥。
本篇文章的分享就到这里了，如果您觉得在本文有所收获，还请留下您的三连支持哦~
