了解HTTPS的这些，才知道这些年是如何被公司监控了网络请求

00 写在前面

话题灵感来源：

木易杨 每日·壹题 2019-07-31： github.com/Advanced-Fr…

本文原理部分参考文章：
《也许，这样理解HTTPS更容易》showme.codes/2017-02-20/…

在日常工作的时候，常会收到这样的警告邮件，某某某又把公司账号密码上传到某笔记了，被处罚了xxx元。

⚠️当然不要将公司的相关内容上传到外网，当然这也是为了保护公司的财产不受到侵害。可我还是想知道是如何做到的，当然公司的抓包以HTTP请求为主。所以HTTPS对于保护我们的一些隐私来说会有多么重要的意义。HTTPS也不是完全不能被监控，只是会稍微麻烦一些。

所以HTTPS及其原理是横竖都要了解的了。这篇文章主要以了解通俗的HTTPS原理为主，如果想知道HTTPS是如何被监控的，文末有我的一些“假想”。

01 如何做到真正的安全？

• 通常的理解是使用各种加密算法，但这只是对这个问题的解决方案。
• 做到真正的安全要保证通信内容只有通信的双方知晓。这句话才说出了HTTPS发展并出现的理由。
• 由于HTTP没有重视这部分内容，没有使用这些加密算法，被抓包分析也就是顺利成章正常的事情了。

02 经常会被问到的：如何一句话总结HTTPS

我的理解：

• HTTPS是通过 对称加密 的方式保证数据只有客户端和Server端知晓，

  【 Client <==对称加密==> Server 】

• 通过 非对称加密 通知客户端 安全的（对称加密所使用）的密钥，

  【 Client <==非对称加密== 数字证书 <=== Server 】

• 通过第三方机构颁发的 数字签名和证书 验证客户端得到用于 非对称加密公钥 的安全性。

  【Client 本地进行验证】

• 客户端使用非对称加密得到的公钥去Server获取对称加密的密钥，用对称加密算法加密请求体完成安全的网络请求。

03 从头理解HTTPS

从头理解HTTPS，这个“头”可以理解成当初设计HTTPS的目的。从通信安全这个目的开始，理解HTTPS的巧妙设计。

可以分为以下几个阶段，从刀耕火种的年代到现在小资生活，才知道美好生活来之不易阿~。

Stage 01： 从对称加密开始。

---

第一阶段： 为了达到 通信内容只有通信双方知晓 这一目的，我们很容易就想到了对数据进行加密算法。那么使用对称加密自然是最安全的选择，最简便的实现方式。如下图所示：

PS： 对称加密： 加密和解密使用一套算法，算法只有A, B 两人知道并使用，一一对应。

• 在密钥S足够安全，且密钥没有分享给其他人使用的前提下，对称加密的算法是可以满足我们的目的的，可以保证通信内容的安全。

• 但是这个实现有一个不可忽略的前提，那就是密钥没有分享给他人使用。但是有些时候我们没有主动去分享它，但是它确实被众多的人所知道了。

• 比如多个Client访问我们的Server的时候。其实也就是相当于我们的密钥S被分享了。这样我们的加密和解密就相当于被公开了，毫无意义（这也是Stage01 阶段最大的问题）。像下图所示。

那么聪明的同学很快就反应过来了，我只需要在我的加密算法上小改动一点就能快速生成出无数的加密算法，給每一个Client都重新分配一个类似的又不完全相同的算法即可保证对称加密的安全性。

这种思考也使我们对HTTPS的探索深入到了第二个阶段。

Stage 02: 确定不同的加密算法。

---

确定不同的加密算法并不难，就像你有无数种方法去锁起来一样东西，难点在于如何通知到每一个Client你锁住东西正确的打开方法。

这里我们可以使用非对称加密的方式。

PS： 非对称加密： 非对称加密是1对N的关系，即一个私钥，N个公钥。公钥加密，只有私钥可以解开。 私钥加密，所有公钥都可以解开。

所以我们只需要把（对称加密算法）密钥 通过非对称加密的方式，在Server上进行私钥加密之后发送给Client，那么Client可以用自己的公钥把这个密钥給解密出来，完成接下来的工作。

小结：

• 在这个阶段我们已经完成了对于（对称加密）密钥 的处理。但是：

• 细心的同学发现了一些问题，这个阶段做的事情也是有一个前提的，那就是我们假设了每一个Client都有我们的公钥。这就为难了。

• 我们不能要求每一个客户端都默认保存我们的公钥把。

• 你可能很快就会联想到我们10年前在使用银行网站的时候，一定要我们安装的那个网页证书把，它其实有一部分功能是在我们的客户端上保存它网站的公钥，完成安全认证。

• 话说回来，那种安装方式真的不友好，要不是非用不可，谁会复杂的安装它呢。

所以这个阶段的问题：

在每一个访问我们网站的Client上，可以使用我们网站认定的公钥就是一个大大的问题。

继续思考公钥的来源，到第三个阶段：

Stage 03： 获取Client非对称加密使用的公钥

---

• 方法一： 向 网站 Server 索要。
• 方法二： 向 网站指定的一个路径去索要。

以上两个方法应该是我们目前为止能想到的两个好主意。我们逐一分析。

• 方法一： 向 Server 索要， 那么如何保证这次请求不被掉包或者修改。再加密么？死循环了。。。卒
• 方法二： 多了一次网络请求，耗时严重，但是也不一定满足我们的要求，不一定保证安全，且流程繁琐。

下面图片展示了方法一中，被中间人修改我们公钥的过程。

我们来看看HTTPS的解决方案。HTTPS 给出的方案和我们最开始否定的方案类似但是又不完全相同，就是在客户端保留一些凭据，通过他们指定机构的信用和影响力。帮助我们完成公钥的验证和安全。

下一个阶段我们来看看这些第三方机构是如何帮助我们辨别真伪，维护安全的。

Stage04 使用第三方机构的证书

---

• 还是先来说一下我们现在阶段遇到的瓶颈问题： Client 无法正确安全的获取我们网站的公钥。
• 其实这个问题出现的原因是，我们不能保证是否有中间人的存在，但是我们又无法分辨他们的身份。
• 那么解决办法是：我们需要对我们的Server的身份进行一次官方的认证，而中间人没有官方认证，这样就能区分身份了。
• 这里的官方认证的本质也是一次非对称加密 ，即官方用私钥加密，客户端用公钥解密，只不过这些公钥提前被浏览器厂商集成到了浏览器里或者操作系统里了，也就是本地存储好了呢~
• HTTPS，要我们的Server拿着要給客户端的公钥，去生成一个被官方认证的数字证书，最后把这个数字证书給Client。Client又用官方的公钥进行解密，得到了正确的用于安全的公钥，进而获得 对称加密的密钥，完成对称加密发送数据。

到了这个阶段，我们已经理解了HTTPS的基本原理的80%，其核心是官方认证和授权的概念。

• 我们要想让浏览器保存我们的公钥就得 使用我们的证书，提示用户下载。这是原始的方案。
• 现在出现了官方机构，直接获得厂商的支持，集成到了操作系统和浏览器里面。

ps： 那我们回想一下当年用过的破解windows和非官方网站下载的浏览器是不是有些后怕呢。

那么既然说到了破解的问题，就引起了另一个思考，毕竟作为完善的方案，一点点的意外都不能马虎。

问题是这样的：客户端是保存了第三方机构的公钥的，也就是可以解析这个厂商的所有证书而且机构在颁发证书的时候又不是仅仅为我们一个网站服务的。也就是说中间人还是有机会去搞破坏。

搞破坏的原理是这样的： 红色为坏人。

• 中间人拦截了我们的请求，在中间掉包了我们的证书。曲解我们的请求。
• 这里中间人只是能 掉包 我们的证书，如果它选择去解密我们的证书，请求就不会进入到Client里面，它的中间人身份就没有意义了。获取不到好处。
• 终极阶段：HTTPS引入了数字签名 的概念来解决证书被替换掉包的问题。

Stage 05 数字签名验证。

---

• 数字签名就是这个数字证书的编号。
• 我们可以通过证书的编码去查询这个证书是机构颁发給哪个Server的
• 比较一下和我们手里拿到的是不是一样的，就可以区分中间人掉包的证书了
• 因为掉包的证书编号查出来的Servrer一定不是我们的Server。我们就不要再解密这个证书了。

• 图中的编号生成方法是一个比喻（并不一定就是简单的MD5）
• 那么这个验证的过程是一个远端请求么？如果是的话，机构的服务要保证 7*24小时100%的可靠，这显然不现实，机构也不是万能的，也不能应对全世界的验证编号的海量请求把。
• 那这么一说这个验证也是离线在客户端验证的喽~ 看看HTTPS怎么做的。

• 第三方机构在颁发数字证书的时候，把数字签名验证的方法也写到了证书上。并同时使用它的私钥进行加密。
• 客户端在拿到数字证书之后，根据提供的方法生成一个编号与获得的证书编号进行比较判断是否相同。

• 这个比较判断的原理很像是我们身份证号的验证方式： 身份证号的校验位会通过一个公式计算前面我们的身份证数字，计算之后的结果和校验位相比较，查看是否有效。一个道理。

小结：

至此，在第三方机构提供的支持下，我们可以获得被安全认证的 公钥，进一步从Server获得对称加密的 密钥， Client的请求被密钥加密后可以对数据进行有效保护。

总体流程：

• 1. CLIENT to SERVER: 索取（非对称加密） 公钥。
• 2. SERVER to CLIENT: 回复一个机构颁发的数字证书。
• 3. CLIENT: 本地验证证书有效性。解析出（非对称加密）公钥。
• 4. CLIENT to SERVER: 使用公钥索取 （对称加密） 密钥。
• 5. SERVER to CLIENT: 回复密钥。
• 6. CLIENT to SERVER: 密钥加密算法，加密发送的数据。

回到标题

• 赶紧回到标题的内容，不然该被说是标题党了。说一下我们是如何被监控的呢。 HTTP的请求没有加密，没有证书。被中间人劫持是必然的。

然后要考虑一个问题：

• 第三方机构的信息和公钥是在我们的浏览器和系统上的。
• 如果通过技术手段，有人在我们的电脑上或者系统层面新增了一个被电脑允许第三方机构，并保存了它的公钥。
• 然后中间人在向这个他们建立的机构上申请证书，就像我们向正规的机构申请一样。
• 在我们电脑上的一个进程再持续的工作，充当中间人的身份持续掉包我们正常访问网站的证书，是不是就可以解析解密我们的请求绕过HTTPS的安全机制。
• 这也就是抓包HTTPS的原理和某些公司使用一些壳子服务（某云壳）或者进程来监控我们的HTTPS网络请求的原因了。

最后：理解了HTTPS原理。还是劝戒，工作的内容还是不要传到私人的云了~ 。