信息网 > 北京信息 > 正文

也许，这样理解HTTPS更容易

网络整理 2019-03-12 19:21

如何做到真正的安全?

这个问题，很多人马上就想到了各种加密算法，什么对称加密、非对称加密、DES、RSA、XX、噼里啪啦~

而我想说，加密算法只是解决方案，我们首先要做的是理解我们的问题域——什么是安全？个人的理解是：A与B通信的内容，有且只有A和B有能力看到通信的真正内容。好，问题域已经定义好了(现实中当然不止这一种定义)。对于解决方案，很容易就想到了对消息进行加密。对于A与B这样的简单通信模型，我们很容易做出选择：

也许，这样理解HTTPS更容易

这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。具体细节不是本文范畴。只要这个密钥S不公开给第三者，同时密钥S足够安全，我们就解决了我们一开始所定问题域了。因为世界上有且只有A与B知道如何加密和解密他们之间的消息。

但是，在WWW环境下，我们的Web服务器的通信模型没有这么简单：

如果服务器端对所有的客户端通信都使用同样的对称加密算法，无异于没有加密。那怎么办呢？即能使用对称加密算法，又不公开密钥?答案是：Web服务器与每个客户端使用不同的对称加密算法：

如何确定对称加密算法

慢着，另一个问题来了，我们的服务器端怎么告诉客户端该使用哪种对称加密算法？当然是通过协商。

但是，你协商的过程是没有加密的，还是会被中间人拦截。那我们再对这个协商过程进行对称加密就好了，那你对协商过程加密的加密还是没有加密，怎么办?再加密不就好了……好吧，进行鸡生蛋蛋生鸡的问题了。

如何对协商过程进行加密

新问题来了，如何对协商过程进行加密?密码学领域中，有一种称为“非对称加密”的加密算法，特点是私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。

也许，这样理解HTTPS更容易

虽然服务器端向A、B……的方向还是不安全的，但是至少A、B向服务器端方向是安全的。好了，如何协商加密算法的问题，我们解决了：使用非对称加密算法进行对称加密算法协商过程。这下，你明白为什么HTTPS同时需要对称加密算法和非对称加密算法了吧?

协商什么加密算法

要达到Web服务器针对每个客户端使用不同的对称加密算法，同时，我们也不能让第三者知道这个对称加密算法是什么，怎么办？使用随机数，就是使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一该才确定加密算法。

这下，你明白为什么HTTPS协议握手阶段会有这么多的随机数了吧。

如何得到公钥?

细心的人可能已经注意到了如果使用非对称加密算法，我们的客户端A，B需要一开始就持有公钥，要不没法开展加密行为啊。这下，我们又遇到新问题了，如何让A、B客户端安全地得到公钥？我能想到的方案只有这些：

方案1. 服务器端将公钥发送给每一个客户端

方案2. 服务器端将公钥放到一个远程服务器，客户端可以请求得到

我们选择方案1，因为方案2又多了一次请求，还要另外处理公钥的放置问题。

公钥被调包了怎么办?又是一个鸡生蛋蛋生鸡问题?

但是方案1有个问题：如果服务器端发送公钥给客户端时，被中间人调包了，怎么办？画张图方便理解：

显然，让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。

使用第三方机构的公钥解决鸡生蛋蛋生鸡问题

公钥被调包的问题出现，是因为我们的客户端无法分辨返回公钥的人到底是中间人，还是真的服务器。这其实就是密码学中提的身份验证问题。如果让你来解决，你怎么解决？如果你了解过HTTPS，会知道使用数字证书来解决。但是你想过证书的本质是什么么？请放下你对HTTPS已有的知识，自己尝试找到解决方案。