这是一篇人人都看的懂 HTTPS 的文章

这是一篇人人都看的懂 HTTPS 的文章

前言

随着互联网日新月异的发展，越来越多的网站开始使用 协议来取代 协议，国外一些知名的互联网企业包括 Apple，Google，Facebook 等都已全部使用了 协议使用逐步的减少，也开始逐步退出历史舞台。

如果人问你为什么要用 协议取代 协议呢？最简单的回答当然是保证网络数据传输安全，但是我们作为一名客户端开发人员， 显然只知道这个答案是不合格的，由于我们在写代码时， 与 并没有值得需要注意的地方, 导致我们很多客户端开发人 员对其并不了解，只知道 会对网络数据传输做加密，而对其工作原理一无所知。

但如果要你想成为一名合格的客户端开发人员，那就必须对 的工作原理有所掌握，这样当我们在日常工作中遇到一些问题的时候，掌握 https 的原理能更有效的帮助我们解决问题；另外，当你求职的时候，也是面试的热门话题，如果你不了解它的基本工作原理，那么这个 offer 就属于别人了。

加密算法

为了更好地了解 的工作原理，我们先熟悉俩个概念：什么是对称加密，什么是非对称加密。

对称加密：这种加密方式就是加密和解密用的是同一个密钥，客户端与服务器可以商议好一个密钥来对数据 进行加密和解密；对称加密的好处是加密解密效率高，但是最大的缺点就是密钥的管理与分配存在风险，在 网络传输的过程中密钥有被中间人拦截的风险。对称加密代表性的加密算法有 DES，AES等。

非对称加密：这种加密方式使用俩个密钥，公钥和私钥，公钥存放在客户端上，私钥存放在服务器上，用公钥加密过的数据 只有私钥才能解开，反之，用私钥加密过的信息也只有公钥才能解开。非对称加密的优点是安全性高，但是对数据加密解密的 效率就比较低了。其代表性的加密算法有 RSA。

当你在求职面试的时候，有可能面试官会问你:"协议 用的是对称加密，还是非对称加密"? 答案是什么？不急，等你看完下面的文章你就知道了。

HTTP 存在的问题

都说使用 进行网络数据传输不安全，但到底问题出在哪里呢？

由于 协议本身不具备加密的功能，在进行 数据传输时，它的信息都是以明文方式发送，很容易发生数据泄露，数据篡改，流量劫持，钓鱼攻击等安全问题，用下面的图 举个例子：

可以看到在 传输过程中，中间人能看到并且可以修改 通信的内容，所以使用 是非常的不安全的。 这个时候可能就有人想到了，既然内容是明文那我使用对称加密的方式将报文加密这样中间人不就看不到明文了吗，于是如下改造：

这样看似中间人看不到明文信息了，但其实在第一次通信的过程中还是会以明文的方式暴露密钥，如果第一次通信被中间人拦截到了，那么密钥就会被泄露，中间人仍然可以解密后续的通信内容，示意图如下：

那可能又有人说我可以让服务器跟客户端私下约定一个密钥用于加解密，这样密钥都是线下的，只有两端的开发人员知道，那中间人破解几乎是不可能的，但是万一密钥泄露，或者客户端不能热更新的情况下，想要换密钥是需要花很多的时间来重新部署的，那这段时间内的损失就不可估量了。

如果用上述的对称加密算法，在工作流程上我们始终无法规避掉风险，那是不是就意味着一个计算机难题由此诞生了？聪明的你可能立马就想到了非对称加密算法，我们通过示意图来了解一下：

可以看到，在客户端中我们用服务器提供的公钥对数据进行非对称加密，然后服务器收到数据后再用私钥对其进行解密，由于中间人没有私钥便无法对网络传输的数据进行解密，因此这段数据传输是绝对安全的。但 的工作流程是真的这样的吗？我在上面讲非对称加密的时候说过，非对称加密的缺点是加密解密的效率很低，对于网络通信，还是需要保证响应速度，如果所有的数据传输都以这样的流程来工作，那通信过程势必会受到影响，那该怎么优化呢！

这就得结合对称加密来一起使用了，充分利用俩者各自的优势，虽然对称加密的加密解密效率很高，但是苦于无法保证密钥传输的安全性，所以我们的优化方式是在客户端与服务器首次通信的时候使用非对称加密，客户端随机生成一个对称加密的密钥，然后用服务器给的公钥进行加密，一旦服务器收到了客户端的消息便用私钥进行解密得到对称加密的密钥，这样双方就通过这种安全的方式获取到了对称加密的密钥，然后通过对称加密进行网络通信，因此通信的工作效率是非常高的。

但是你以为流程到此就结束了吗？就真的安全了吗？其实并没有，细心的你可能会问，那客户端的公钥服务器该怎么给它呢？虽然说公钥是对外公开的数据，但是如果中间人对其进行拦截并篡改，改成了他自己的公钥，客户端收到伪造的公钥对数据进行加密，那么该数据就有可能被中间人用他的私钥解密，数据传输的安全性再次得不到保证。

事情到这一步似乎是进入了死胡同，因为无论如何我们都无法保证我们获取到的是一个真实可靠的公钥，那该怎么办呢？

这个时候就轮到了 CA 出场了。CA 是负责发放和管理数字证书的权威机构，承担公钥体系中公钥的合法性检验的责任。那它是怎么帮助我们解决这么一个历史难题的呢？别急，接下来我们开始一步步的解析。

首先，服务器的管理者会向 CA 机构进行申请，然后将自己的公钥，组织信息，域名信息等提交上去, CA 机构会使用自己的私钥对这些信息进行加密并生成数字证书，数字证书中包含了申请人的公钥，数字签名，组织信息， 域名等，然后 CA 机构将制作好的数字证书返回给申请者，申请者只需要将获得的数字证书配置到服务器上即可。

当客户端向服务器请求时，首先服务器向客户端返回这个数字证书，客户端则会用 CA 机构的公钥来校验这个数字证书的有效性。如果校验成功，就说明这个数字证书是合法的，当然也就获取到了我们自己的公钥。通常我们可以在浏览器的地址栏中来查看证书的信息，如图所示：

公钥获取到了以后，那就可以继续我们上面所说的非对称加密与对称加密一起使用的工作流程了。

如果校验数字证书失败，则说明这个数字证书是伪造的，很有可能已经被中间人篡改了，通常在浏览器中会显示如图所示的界面：

那到这里有的人又会问到那我们怎么样才能得到 CA 机构的公钥呢？

这个问题就比较好办了，因为现在的操作系统中都会内置所有主流 CA 机构的公钥，在我们解密的时候，只要去遍历系统内所有内置的 CA 机构的公钥，只要有一个 CA 机构的公钥能解密数字证书，就说明这个公钥是合法的。

Windows 电脑系统内置的证书如下:

MAC 电脑系统内置的证书如下：

到这一步，已经可以看到我们的网络传输流程已经非常安全可靠了，但说了这么多对 怎么只字未提，其实上述的流程就是 的工作流程。那么现在我们回过头来看文章中提到的面试题，想必大家已经知道了答案，那就是真的是一点风险都没有嚒！然而并不是这样，打个比方，假如 CA 机构针对申请者信息的验证不是那么严格，恰巧有位黑客又知道你服务器的域名等相关信息，然后去申请一个合法的数字证书，那么就可以用来拦截浏览器与服务器之间的通信，所以所有的这一切都要建立在 CA 机构的良心基础上。

好了，本篇文章到这里就结束了，此篇文章是我以我理解 的立场来写的，内容也尽量以通俗易懂的方式呈现给大家， 欢迎大家批评指正。

​​HelloWorld杰少​​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。