HTTPS的重大漏洞：豆腐（TOFU）

“豆腐”漏洞简介

之前写了一篇https的介绍，这里，文中从软件学公理一步步推导出https的实现原理，但是貌似在后面一部分出现了某种概念断层，就是在“服务器如何认证浏览器”这一点上没有安全的保证。后来仔细研究了一下，原来并不是因为我的知识盲区，而是https确实有一个漏洞。

先放出结论，TOFU漏洞如图所示：

 

首先需要理解https和ssh的区别。

HTTPS = SSH + CA

如何理解上面的公式？我们需要知道https和ssh（使用公钥加密）实现原理的区别。

首先，无论是https还是ssh都是使用不对称加密的，不对称加密是为了实现认证，进而可以安全的协商后续的对称加密。其中最关键的一部是认证，即如何安全的交换公钥。注意，这里是最关键的一部分，一旦双方公钥安全的交到对方手中，之后任何安全问题迎刃而解。所以整个公钥体系最关键的问题就是如何安全的交换公钥。

私底下交换公钥不就好了？

对啊，私下或者线下交换下不就好了？私下交换公钥确实很安全,SSH就是这样玩的，比如两人到一间咖啡馆一边聊天一边顺手互换一下自己的公钥纸条，搞定！线下交换确实是一条绝对安全的信道，不过SSH选择了另一条安全通道：https在线网页。通过安全的网页手动提交用户自己的公钥，如图所示。

像GitHub或者gitlab这种的SSH公钥交换模式虽然也是线上，需要注意的是，线上手动上传SSH key一定要保证当前页面是安全的https，才能放心的上传key。

但是这样却需要手动操作（需要花费你若干分钟的时间），没有实现自动化，正真实现自动化交换公钥的是HTTPS。HTTPS不需要你手动的和对方交换公钥，而是通过一个第三方机构的监督来实现自动交换，这个机构就是CA。

如何利用CA证书来认证的原理就不讲了，参考之前的文章。

所以说，https和SSH的本质上是一样的，只是交换公钥的时候，前者是通过CA来交换，后者是手动交换。即：HTTPS=SSH+CA。

或者说SSH是https的删减版。

IPv4时代下的豆腐：单向认证

无论是https还是ssh都只实现了SSL标准的“一半”，即单向认证：对等体中只有一方的公钥安全的交到对方手中，反之则不能保证安全。

https下面，浏览器的CA认证了服务器的证书，但是服务器无法证实浏览器的证实性；SSH下面，客户端的公钥安全的给到了GitHub，但是GitHub的公钥却没有安全给到客户端。https和ssh的认证模型如下图：

所以，无论是https还是ssh，只有单方向的公钥传递是可靠的，另一个方向默认采用TOFU（Trust on first use）的原则，即首次收到对方公钥的时候，选择信任。拿ssh举个例子：

一个用户Jim，通过ssh连接cloud.jameshfisher.com。

一旦服务器cloud.jameshfisher.com有了Jim的公钥，Jim可以像这样通过SSH连接到机器：

jim@laptop:~$ ssh -i ~/.ssh/id_ed25519 cloud.jameshfisher.com
The authenticity of host 'cloud.jameshfisher.com (35.190.176.201)' can't be established.
ECDSA key fingerprint is SHA256:vm5X6LZPUv7ZTy2oliLO9qKJy5svHvBHElL1YfouKWc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'cloud.jameshfisher.com,35.190.176.201' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.13.0-1011-gcp x86_64)

当Jim第一次连接cloud.jameshfisher.com，他的本地SSH询问Jim服务器密钥（带有一些ECDSA密钥指纹）是否真正属于密钥cloud.jameshfisher.com。jim说yes。每个人总是如此。然后他的本地SSH将此密钥添加到以下列表中known_hosts：

jim@laptop:~$ cat ~/.ssh/known_hosts | grep cloud.jameshfisher.com
cloud.jameshfisher.com,35.190.176.201 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJBa4c8wVzMp+ed6nLQAmUKXZ8ENXc6NpEzfTY2sjMqYJlWYktAeihlLOf5QnatkYsXnsP7Pu+yd2xF9M8dY4u0=

将来，如果Jim尝试SSH cloud.jameshfisher.com，他的本地SSH客户端将要求服务器具有密钥known_hosts。Jim及其本地SSH使用的此策略称为“首次使用时信任”或“TOFU（豆腐）”。

如上，SSH至少还prompt用户是否信任服务器的指纹，https直接就让web服务器信任了，没有选择的余地，所以许多网站要求用户登录才能查看，使用一些功能，目的就是为了对客户端进行认证。

 

TOFU漏洞的危险程度：极小

TOFU有一个弱点，即每当员工第一次尝试SSH到机器时，都可能存在中间人攻击。随着更多的员工和更多的服务器，多对多关系的膨胀，中间人攻击的机会呈指数增长。尽管存在这种弱点，但默认情况下，SSH客户端使用TOFU，因此大多数组织都使用TOFU。

https同理，当服务器收到客户端加密后的公钥时，也无法保证这个公钥就是刚才的用户。

综上而述，目前人类在金融机构，企业，政府广泛使用的基于RSA加密的认证体系SSL，一直存在着这样一个根本性的漏洞，是不是听上去比“量子计算机可能破解RSA”还可怖？

然而幸运的是，TOFU漏洞的危险程度微不足道，原因如下：

• 1. 破解成本很高。首先中间人想要利用TOFU攻击SSL，首先需要成为“中间人”，想要在互联网上找到这样一个“伏击点”是非常难的，如果是在企业网络这样的安全的内网环境下攻击的话，就是难上加难了。
• 2. 攻击机会很少。其次，tofu唯一的攻击机会是2台机器首次建立连接的时候，这时才会交换公钥，如果这时候没抓住时机攻击，之后他们都使用缓存的公钥，就再也没机会了。
• 3. 攻击成本很高。最后，假设上面2点你都成功了，那接下来你要做的事情会令你崩溃：比如要攻击ssh，你就要使用用户的公钥来模拟一台目标机器的操作系统，而且哪怕模仿时出现一点点瑕疵，比如少了一个文件，少了一条记录，用户都会察觉到，然后通过其他方式发现你的存在，你之前辛苦的模仿工作都白费了！

综上所说，与其利用TOFU漏洞来进行网络攻击，远不如雇人把仇家胖揍一顿来的实在。而且未来IPv6时代下，人人都有ip地址，所有的ssl连接都通过CA来认证，那时候TOFU就真的不存在了。

---

完。