为什么 SSH 不使用互锁协议？

Question

看来SSH的设计师们很在意中间人攻击。

他们的方法是，在您第一次连接到服务器时保存服务器的公钥指纹（并希望用户在第一次连接时不要从受毒网络连接，例如如果他有计算机中的病毒）。然后，用户在下次连接到该服务器时使用指纹验证服务器的公钥。

在实践中，我发现许多用户只是忽略了有关指纹不匹配的警告，并认为这是由于重新安装服务器造成的。只是 MITM 攻击很难进行而且很少见，你永远不用担心。此外，很多时候用户想要在许多不同的计算机上使用 ssh，并且他不会费心将所有指纹导入他可能想要使用SSH 的任何计算机上（嘿，你能看看我的网站为什么关闭，我'我慌了！我不在办公室，我去最近的网吧看看）。

公平地说，可以使用DNSSEC 并将DNS 服务器用作CA。但是我从来没有看到在实践中使用过。无论如何，这不是协议的强制性部分。

多年来，我认为没有预先共享的秘密就无法避免 MITM，但我最近一直在阅读 Bruce Schneir 的优秀“实用密码学”，其中他提到了 interlock protocol。

1. Alice 将她的公钥发送给 Bob。
2. Bob 将他的公钥发送给 Alice。
3. Alice 使用 Bob 的公钥加密她的消息。她将一半的加密信息发送给 Bob。
4. Bob 使用 Alice 的公钥加密他的消息。他将一半的加密消息发送给 Alice。
5. Alice 将另一半加密消息发送给 Bob。
6. Bob 将 Alice 的两半信息放在一起，并用他的私钥解密。 Bob 将另一半加密消息发送给 Alice。
7. Alice 将 Bob 消息的两半放在一起，并用她的私钥对其进行解密。

现在，Mallory 必须在协议的第 (3) 步中向 Bob 发送一些东西，在他收到 Alice 的一半消息之后，即使他无法解密它，直到他在 (5) 中从 Alice 那里得到所有信息。他必须向 Bob 编造一条消息，而 Bob 很可能会注意到他在编造，比如说，在他 ls 他的主目录之后。

SSH 为什么不使用这样的方案？它似乎真的符合它的目标。它不需要任何其他实体，这使得 MITM 攻击变得更加困难。

这是与生俱来的吗？我对问题的理解有缺陷？或者只是设计者认为额外的安全性不值得让协议复杂化？

PS： 如果您认为这会导致过多的开销，您可以强制协议的用户仅对连接中的第一个 10K 数据使用互锁，因此在实践中它并没有太大关系，但 MITM 会越难越难。

更新： here 描述的对联锁协议的攻击，并不意味着 MITM 攻击是可能的，它确实意味着如果在通信期间发送单个密码，MITM 可以拦截它并且用户只会看到超时错误。

更新 2： Eugene, raise 的观点是有效的。联锁协议不允许身份验证。也就是说，您仍然无法确定如果您连接到example.com，它确实是example.com，而不是malicious.com 冒充example.com。如果没有DNSSEC，您就无法确定这一点。因此，例如，如果您正在 SSH 进入导弹发射井，并写入 launch_missile -time now（例如，不使用 ls 来验证服务器确实是导弹发射井中的服务器），那么您可能实际上是在恶意服务器上写的，现在敌人知道你要向他发射导弹了。联锁协议确实无法阻止这种类型的攻击。

但是，如果我正确理解协议，则可能会阻止更危险且非常实用的攻击。如果使用联锁协议，即使你对example.com一无所知，你也不可能将SSH 发送到你的服务器，并且有人会窃听整个SSH 会话。我认为这种攻击的可能性更大。

也许SSH 不关心 MITM 攻击？我认为不是，例如见Putty FAQ:

那些烦人的主机键提示是 SSH 的重点。没有他们， 所有的密码技术 SSH 用于保护您的会话正在做 无非是让攻击者的 工作稍微辛苦一点；代替 坐在你和服务器之间 使用数据包嗅探器，攻击者 必须实际上颠覆路由器和 开始修改返回的数据包 来回。但这还不是全部 比嗅探要难得多；和 没有主机密钥检查，它会去 完全未被客户发现或 服务器。

他显然是在谈论 MITM 攻击，而不是在谈论服务器身份验证。我认为使用联锁协议可以清楚地防止 Putty FAQ 中提到的攻击，但我仍然不明白他们为什么不使用它。

Answer 1

我看不出互锁协议如何防止 MITM。

问题不在于如何交换密钥，而在于如何信任它们。您正确地指出，人们忽略了键不匹配的警告。这确实是最大的缺陷，但是你描述的协议并没有解决密钥来源的验证问题。 SSL 使用 X.509 证书和 PKI 来验证信任。 SSH 也可以使用证书，但几乎没有 SSH 软件支持它们。