一文读懂HTTPS

前言

关于HTTPS的文章有不少，你们的文章讲的那是真的详细，功底我着实佩服。虽然已经有了这样优秀的文章，但不影响我写做的热情，学习知识，分享是必不可少的一环。文章不是照搬，而是本身理解加工后纯手打的。

学习前端开发果真仍是绕不开计算机网络基础，今天面试挂在了这里，痛定思痛，让咱们一块儿来了解下HTTPS究竟是个什么玩意。

灵魂拷问

你是否曾认为，证书是用来加密的？😄

对称加密

通讯双方，使用同一个密钥对信息加密和解密。只有知道密钥的人才能获取内容。

但通讯双方必须约定好密钥，且不能泄露密钥。而实际上，只要使用网络传输，就存在报文泄露的风险。况且HTTP协议本就是明文传输，双方约定密钥的过程，彻底是众目睽睽之下。这种状况下没法保证你的密钥没有被第三方截获。隔墙有耳一说，对吧？因此出现了非堆成加密

非对称加密

通讯双方每一个人都有两把钥匙，公钥任何人均可以知道，私钥只有本身知道。

且存在这样一个特色：使用公钥加密的内容，只有对应的私钥才能解开，使用私钥加密的内容，只有对应的公钥才能够解开。所谓，非对称。

根据这样的特色，A发消息给B，使用B的公钥加密，B收到后使用本身的私钥解密，就能够获取到内容了。

因此通讯时，双方首先要互换公钥。A和B通讯开始后，中间人彻底能够在截获A的公钥后，替换成本身的公钥发送给B，只要B使用该公钥加密，中间人就可使用本身的私钥解密，得到内容。双方的通讯虽不至于众目睽睽，却也暴露给了中间人，总归是不安全的。

你可能要问了，那B不用中间人的公钥加密不就行了？

实际上B并不知道该公钥是否是A的，A也一样不肯定它收到的公钥是否是来自B。

因此引出了一个问题。A如何判断你加密使用的公钥确实是B的，而不是中间人的？即，如何判断公钥身份是否有效？

数字证书：

联系实际，考虑到身份证实必需要第三方机构，咱们必须无条件信任它。本身是没办法证实本身的身份的。这个第三方机构通常是CA（Certificate Authority），颁发证书的具体过程以下：

B将本身的我的信息，和公钥发送给CA机构（这里会不会出现中间人攻击？），CA机构使用哈希算法对发来的我的信息和公钥进行计算，生成一个摘要，并使用CA本身的私钥进行加密生成数字签名。最后将数字签名和原信息（B的公钥和信息）合并，生成数字证书。

这里用到了哈希算法，它的特色是，只要原信息变化，计算获得的值就会发生巨大的变化。以此来确认内容是否遭到篡改

再借鉴一张图：

因此，在通讯时，B先将本身的证书发送给A，A使用一样的哈希算法，对证书内B的信息进行计算，生成一份摘要。同时对证书内的数字签名进行解密，拿到事先加密的摘要，对比两份摘要的内容是否一致，即可以肯定公钥是否被篡改。

最根本的问题

1. 公钥发送给CA机构的过程当中，不会被中间人拦截吗？
2. 数字签名是使用CA的私钥加密的，解密须要使用CA的公钥，咱们如何获取？获取公钥的过程当中若是又被截获了，岂不成了死循环？

根证书

如下内容摘自百度百科

根证书是CA认证中心给本身颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。从技术上讲，证书其实包含三部分，用户的信息，用户的公钥，还有CA中心对该证书里面的信息的签名。验证一份证书的真伪（即验证CA中心对该证书信息的签名是否有效），须要用CA 中心的公钥验证，而CA中心的公钥存在于对这份证书进行签名的证书内，故须要下载该证书，但使用该证书验证又需先验证该证书自己的真伪，故又要用签发该证书的证书来验证，这样一来就构成一条证书链的关系，这条证书链在哪里终结呢？答案就是根证书，根证书是一份特殊的证书，它的签发者是它自己，下载根证书就代表您对该根证书如下所签发的证书都表示信任，而技术上则是创建起一个验证证书信息的链条，证书的验证追溯至根证书即为结束。因此说用户在使用本身的数字证书以前必须先下载根证书。

通常来讲，根证书是内置在操做系统/浏览器中的，随操做系统的发布而发布。你信任操做系统，也就信任了这份证书。这就是证书链条的终点。

HTTPS

终于到了HTTPS。前面咱们提到了加密算法和证书。HTTPS是如何选择的？

首先，安全起见，咱们应该使用非对称加密算法。但实际上这种算法的效率并不够高，能够想象，存在两次加密解密的过程。而对称加密算法的效率就还算不错。因而产生了这样一种思路：

使用对称加密算法来传输信息，但密钥使用非对称加密算法来传输。因此但愿你们牢记：HTTPS中，非对称加密算法，仅用来传递对称加密算法的密钥。

握手过程

HTTPS握手过程分为四个阶段：

1. 浏览器发起HTTPS请求，生一次个随机数，附带上支持的加密算法列表和协议版本号。
2. 服务器验证协议版本号是否一致，一致则生成一个随机数，随证书一同发送回客户端，不然拒绝请求。
3. 浏览器经过根证书验证服务器证书是否有效，如有效则说明证书中的服务器公钥有效。生成一个随机数，再生成一个全部内容的哈希值（一共三个随机数），并使用服务器公钥加密后发送。若证书无效，则浏览器提示风险。
4. 服务器接收到以后，使用私钥解密发来的内容，并对全部内容进行一样的哈希值计算，再和收到的哈希值比对。若内容一致，则经过三个随机数按照约定的加密算法生成会话密钥（也就是对称加密密钥），并回应客户端握手完成。

注意到，前两次握手过程是明文传输的。接下来，客户端与服务器进入加密通讯，就彻底是使用普通的HTTP协议，只不过用会话密钥来加密内容

为何须要三个随机数？这三个随机数又被称为pre-master key

引用d520的解释：

不论是客户端仍是服务器，都须要随机数，这样生成的密钥才不会每次都同样。因为SSL协议中证书是静态的，所以十分有必要引入一种随机因素来保证协商出来的密钥的随机性。 对于RSA密钥交换算法来讲，pre-master-key自己就是一个随机数，再加上hello消息中的随机，三个随机数经过一个密钥导出器最终导出一个对称密钥。 pre master的存在在于SSL协议不信任每一个主机都能产生彻底随机的随机数，若是随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret做为密钥就不合适了，所以必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能彻底不随机，但是是三个伪随机就十分接近随机了，每增长一个自由度，随机性增长的可不是一。

断开链接后如何恢复：

1. session ID：每一次会话都有一个编号，会话中断后再次链接须要客户端给出这个编号。服务器有这个记录则不用从新链接。此种方式对分布式集群不太友好
2. session ticket：只有服务器能解密，里面包含会话信息。是在上一次会话中发给用户的。

参考

1. 【阮一峰】SSL/TLS协议运行机制的概述
2. 【码农翻身公众号】一个故事讲完HTTPS