新人向-从零开始设计一个安全的通信协议

网络上有大量关于 HTTPS 的技术文章，但是大部分文章都在以“英译汉”的方式，把 TLS 的握手流程讲出来。

本文将尝试从“如何实现”的角度，通过从零开始设计一个安全的通信协议的方式，帮助读者加快对信息安全的理解。

本文内容和 TLS 的设计思想基本一致，但是某些细节可能略有不同。

鉴于网络上的文章质量参差不齐，建议有兴趣的读者通过阅读官方文档 rfc5246 的方式了解 TLS 的详细设计。

http 面临的问题

HTTP 面临的三个安全问题分别是：eavesdropping（窃听）,tampering（篡改）,message forgery（信息伪造）。

浏览器和服务器进行信息传递时，会通过第三方转发信息。

此时，信息安全面临三个问题：

• 信息内容会被第三方知道=》窃听
• 第三方可以修改信息的内容=》篡改
• 第三方可以丢弃服务器的信息，并假装服务器返回虚假的信息=》信息伪造

0x1 通过签名解决信息伪造和篡改

为了防止第三方伪造信息，我们很容易的想到通过 签名 的方式。

讲解签名之前，我们需要先对非对称加密方式以及消息摘要：（Digital Digest）有所了解。

对称加密是通过同一份密钥加密和解密数据，而非对称加密则有两份密钥，分别是公钥和私钥，用公钥加密的数据，要用私钥才能解密，用私钥加密的数据，要用公钥才能解密。

常用的非对称加密方式有:RSA、ECC。

具体的原理，这里不进行展开。我们只需要了解用于签名的非对称加密需要满足的两个特性即可：

• 公钥非常短：降低客户端加密的计算量

• 私钥非常长：防止第三方伪造或篡改，防止服务器抵赖。

非对称加密通常对等待加密的信息长度有要求，所以，我们一般只对消息摘要加密。

消息摘要：（Digital Digest）又称为指纹（Finger Print）。可以通过单向哈希(one-way hash)函数，为不定长度的信息生成一个固定长度的摘要。

通信安全的第一个要求：服务器的私钥要保证安全

通信安全的第二个要求：安全可靠的非对称加密方式。比如 2048位的RSA加密

通信安全的第三个要求：安全可靠的摘要算法，如果摘要算法的冲突非常多，则很容易被第三方攻击

有了以上知识，我们来看一下数字签名是如何进行的？

签名：
通对某一份数据进行单向哈希，缩短等待加密信息的长度=》单项哈希
通过私钥对信息摘要进行加密运算并生成签名，表示我认可了这份数据（只有我拥有私钥，第三方难以伪造）=》签名

验签：
通过公钥解析签名
对数据进行单向哈希
判等

我们可以模拟一下会话的握手阶段的通信流程：
浏览器：hello
服务器：服务器公钥 + encrypt(服务器公钥，服务器私钥)
浏览器：encrypt(hash(信息)，服务器公钥) + 信息
服务器：encrypt(hash(信息)，服务器私钥) + 信息

上面的通信方式是不是安全多了？

且慢，如果服务器返回公钥时，被第三方拦截，然后替换为第三方的公钥，我们该如何怎么办？

考虑到把所有网站的公钥提前存储到浏览器中并不现实（数量巨大，并且新增公钥、撤销公钥都极为不便）。我们可以提前浏览器内置一份或多份公钥（根证书），然后再把流程升级一下：

会话的握手阶段的通信流程：
浏览器：hello
服务器：服务器公钥 + encrypt(服务器公钥，第三方私钥)
浏览器：encrypt(hash(信息)，服务器公钥) + 信息
服务器：encrypt(hash(信息)，服务器私钥) + 信息

实际上，浏览器会通过一条证书链验证服务器的公钥是否安全
通信安全的第四个要求：不要随意添加根证书。比如，为了安装一些软件or游戏，为了访问某些网站

但是，签名在解决信息伪造和篡改的同时又引入了另外一个问题：性能消耗。

虽然只需要对摘要信息进行签名，但是，它依然给服务器带来了非常巨大的运算压力。
一般情况下，签名操作会导致服务器的处理速度变为原来的万分之一甚至更低（根据算法的不同，实际情况可能会有数量级的变化）。

并且，它还面临一个非常巨大安全问题：窃听。第三方仍然可以看到通信内容。

0x2 引入对称加密算法降低性能消耗并解决窃听问题

既然非对称加密对性能影响巨大，剩下的唯一方案是对称加密。

因为服务器需要和数量众多的浏览器进行通信，所以，每条通信用到的对称加密密钥都应该是不同的。否则，浏览器和服务器之间的通信依然会被第三方解密。

引入对称加密后，就可以再次升级通信流程：

会话的握手阶段的通信流程：
浏览器：hello
服务器：服务器公钥 + encrypt(服务器公钥，第三方私钥) + 第一个随机数
浏览器：encrypt(第二个随机数，服务器公钥)

双方根据PRF算法生成一个对称加密的密钥并用于之后的通信：

浏览器：encrypt(hash(信息)，对称密钥) +encrypt(信息，对称密钥)
服务器：encrypt(hash(信息)，对称密钥) +encrypt(信息，对称密钥)

Master_key = PRF(premaster_secret, “master secrect”, 随机数1+随机数2)其中 PRF 是一个随机函数，定义如下：PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed)

这种双方各自生成一个随机数的方式可以应对浏览器或者服务器单方面出现漏洞（随机数不随机）的情况。

与此同时，在一次会话的建立中，服务器只需要解析一次就可以完成整个会话。

安全通信的第四个要求：安全可靠的随机数生成器

实践中，TLS 要求，“浏览器在发起 hello 请求时，发送另外一个随机数来增加随机性"

安全故事:1996年，研究人员就发现了网景浏览器1.1的伪随机数发生器仅仅利用了三个参数：当天的时间，进程ID和父进程ID。在1996年，利用当时的机器仅需要25秒钟的时间就可以破解一个SSL通信