关于软件设计的两三事:不完美的HTTPS

随着互联网在各个领域的应用不断加深，HTTP协议传输的内容也从最一开始“可公开的知识”变为了“高敏感的隐私数据”，比如用户的账号密码、金融的交易数据、企业的核心信息等等。这些数据对于安全性的要求非常的高，而HTTP协议原有的明文传输设计根本无法满足这些使用场景的安全性要求。

为了解决这样一个安全方面的缺陷，工程师为HTTP协议打上了一个安全补丁。于是，HTTPS协议诞生了。

从本质上来说，HTTPS协议并不是一个全新的协议，它其实是在HTTP的基础上增加了一层安全层。

那么这个新加入的安全层是怎么工作的呢？这里我们可以参考一下古代军队的通信过程。为了保障军队之间通信的安全，机智的通信人员为整个通信过程增加两道安全措施，分别是身份验证和内容加密。

首先是身份验证，这也是整个通信过程当中最重要的一个环节。对于通信双方而言，要想开始一段通信，首先要做的就是确认通信的对象是你真实想要的对象。那么，要怎么确认对方是真李逵而不是假李鬼呢？为了确认身份的真实有效，朝廷会为每个军队颁发代表各自身份的印信。通过这些官方发布的印信，军队双方就可以在接收到信件时，鉴别信件发布者身份的真实性。

同样的，在HTTPS的身份验证体系中也存在着这样一个可以颁发身份令牌的机构——CA机构。虽然这个CA机构是一个非政府性质的机构，但是它的准入要求相当的严格，并且由四大根证书库（微软、苹果、谷歌以及Mozilla）背书，所以我们可以认为由这些CA机构颁发的身份证书是可靠的。

如果一个网站想要开启HTTPS协议，它就必须向这些权威的CA机构申请一份用于身份验证的数字证书。用户每次向网站发起HTTPS请求时，网站的服务器需要先将这张数字证书发送给用户，让用户的浏览器根据本地预装的证书库进行身份校验。当确定身份没有任何问题之后，才会进行下一步操作。

在确认了身份之后，我们的通信过程就安全了吗？并不是。此时我们传递的内容仍然是以明文的方式进行的。

设想一下，在我们没有进行任何加密操作的情况下，是否所有人都可以在通信过程中看到并读懂传递的内容，甚至可以尝试对这些内容进行篡改。所以，要想保证传输过程的安全，就必须要对传输内容进行加密处理。

在经过了这两道措施之后，通信过程的安全得到极大的保障。注意，是极大的保障，而不是绝对的保障。为什么这么说呢？这里主要有以下两个原因。

首先是身份验证环节。如果有人使用了过期的证书或是伪造的证书，此时的浏览器虽然会做出一些警告，但并不会屏蔽这个网页让你无法访问。如果你强行忽略浏览器的警告，你依然可以完成本次的访问，只不过你的数据安全就没有办法得到保障了。这就像你明知道这是一份伪造的书信，但你还是要去看它、去相信它，那么谁来也拯救不来你被欺骗的命运。

其次是用户端/服务端的安全问题。如果通信的这两头本身就是存在问题的，比如客户端被病毒攻击植入了恶意的根证书，又比如服务端压根就是一个钓鱼网站，只不过它上了一个正规牌照。面对这些情况，HTTPS协议也是没有办法保证数据传输安全的。

说到这里，我们其实不难看出，HTTPS 就像一辆装甲运钞车，它能保障钱在路途过程中的安全，但不能保证收钱的人不是骗子，也不能保证钱到了金库以后一定就是安全的。

既然HTTPS协议并不是完美无缺的，那我们为什么还要使用它呢？

做出这样一个决定的原因其实很简单：就目前而言，在保障传输层安全的所有方案中，HTTPS协议的设计方案是性价比最高的。

从上面的设计方案中我们可以看出，HTTPS协议在安全方面只专注于保护传输通道本身，通信双方各自的安全问题需要由各自单独解决。这样的做法让HTTPS协议能够更好地独立于各种业务逻辑之外，整个方案的实施也变得更加的简单和通用，完全不会出现和各种业务场景过度耦合而造成的复杂度和实施成本过高的问题。

虽然说依然会存在上面谈到的一些问题，但是这些问题可以在用户端和服务端通过其他业务手段来解决或者降低它的风险。