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

Question

似乎SSH设计师在中间攻击中非常关心人.

他们的做法是,以节省服务器的公钥指纹在你连接到服务器的第一时间(希望用户没有在第一时间从中毒的网络连接,例如,如果他在一个病毒电脑).然后,用户在下次连接到此服务器时使用指纹验证服务器的公钥.

在实践中,我发现许多用户只是忽略了有关无法比拟的指纹的警告,并假设它是由于服务器重新安装.只是MITM攻击是如此难以进行和罕见,你永远不会担心它.此外,很多时候用户想要使用ssh许多不同的计算机,并且他不会费心将所有指纹导入到他可能想要使用的任何计算机SSH上(嘿,你能看看为什么我的网站出现故障,我感到恐慌!我不在办公室,我会去最近的网吧看看).

公平地说,可以使用DNSSEC和使用DNS服务器作为CA.但是我从未见过在实践中使用过的东西.无论如何,它不是协议的强制性部分.

多年来我一直认为没有预先设定的秘密就无法避免MITM,但我最近一直在阅读Bruce Schneir的优秀"实用密码学",在那里他提到了互锁协议.

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必须在收到Alice的一半消息之后,在协议的第(3)步中向Bob发送一些内容,即使他无法解密它,直到他从(5)中的Alice获得所有内容.他必须给Bob制作一条消息,Bob可能会注意到他正在制作他ls的主目录之后.

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

这是固有的吗？我对这个问题的理解存在缺陷吗？或者只是设计师认为额外的安全性不值得使协议复杂化？

PS: 如果你认为它会造成太多的开销,你可以强制协议的用户使用互锁仅对第一10K在连接数据的,所以在实践中它不会太大的关系,但MITM会更从来没有那么困难.

更新: 描述的联锁协议的攻击在这里,并不意味着MITM攻击是可能的,它意味着如果通信期间发送一个密码的MITM可以拦截它,用户将只能看到超时错误.

更新2: 点Eugene,加注有效.互锁协议不允许验证.也就是说,你仍然无法确定如果你正在连接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软件支持它们。