为什么 SSH 不使用互锁协议？
看来SSH 设计者非常关心中间人攻击。
他们的方法是，在第一次连接到服务器时保存服务器的公钥指纹（并希望用户在第一次时不会从中毒的网络进行连接，例如，如果他的网络中有病毒）电脑）。然后，用户下次连接到该服务器时使用指纹来验证服务器的公钥。
在实践中，我发现许多用户只是忽略有关不匹配指纹的警告，并假设这是由于服务器重新安装造成的。只是 MITM 攻击很难进行，而且很少见，所以你永远不用担心。此外，很多时候用户想要在许多不同的计算机上使用 ssh，并且他不会费心将所有指纹导入到他可能想要使用 SSH 的任何计算机上（嘿，你能看看为什么我的网站挂了，我很恐慌！我不在办公室，我会去最近的网吧看看）。
公平地说，我们可以使用 DNSSEC 并使用 DNS 服务器作为 CA。但我从未见过它在实践中使用过。无论如何，它不是协议的强制性部分。
多年来，我认为没有预共享秘密就无法避免 MITM，但我最近读了 Bruce Schneir 的优秀《实用密码学》，其中他提到了 互锁协议。
- 爱丽丝将她的公钥发送给鲍勃。
- 鲍勃向爱丽丝发送他的公钥。
- Alice 使用 Bob 的公钥加密她的消息。她将一半的加密消息发送给鲍勃。
- 鲍勃使用爱丽丝的公钥加密他的消息。他将一半的加密消息发送给爱丽丝。
- Alice 将加密消息的另一半发送给 Bob。
- 鲍勃将爱丽丝消息的两半放在一起，并用他的私钥解密。鲍勃将加密消息的另一半发送给爱丽丝。
- Alice 将 Bob 消息的两半放在一起，并用她的私钥解密。
现在，在收到 Alice 的一半消息后，Mallory 必须在协议的步骤 (3) 中向 Bob 发送一些内容，即使他在 (5) 中从 Alice 那里获得所有消息之前无法解密该消息。他必须向 Bob 伪造一条消息，而 Bob 很可能会注意到他正在伪造，例如，在他ls他的主目录之后。
为什么SSH没有使用这样的方案呢？这似乎确实符合其目标。它不需要任何其他实体，并且它使 MITM 攻击变得更加困难。
这是固有的东西吗？我对问题的理解有缺陷吗？或者只是设计者认为额外的安全性不值得使协议复杂化？
PS： 如果您认为这会导致太大的开销，您可以强制协议的用户仅对连接中的前 10K 数据使用互锁，因此实际上这不会太重要，但 MITM 仍然会更加困难。
更新： 此处描述的对互锁协议的攻击并不意味着 MITM攻击是可能的，这确实意味着如果在通信期间发送单个密码，MITM 可以拦截它，并且用户只会看到超时错误。
更新2： 尤金提出的观点是有效的。互锁协议不允许身份验证。也就是说，您仍然无法确定您连接到 example.com 时是否确实是 example.com，而不是 malicious.com 冒充 example.com。如果没有 DNSSEC，您就无法确定这一点。例如，如果您要通过 SSH 连接到导弹发射井，并写入 launch_missile -time now（例如，不使用 ls 来验证服务器确实是导弹发射井中的服务器），可能是您实际上在恶意服务器中编写了该服务器，现在敌人知道您即将向他发射导弹。互锁协议确实无法阻止这种类型的攻击。
但是，如果我正确理解该协议，则可能会阻止更危险的攻击和非常实际的攻击。如果使用互锁协议，即使您对example.com一无所知，您也不可能SSH到您的服务器，并且有人会窃听整个 SSH 会话。我认为这种类型的攻击更有可能发生。
也许 SSH 不关心 MITM 攻击？我认为不是，例如参见 Putty 常见问题解答：
那些烦人的主机键提示是 SSH 的全部要点。没有他们， 所有加密技术 SSH 用于保护您的会话正在做的事情 无非是让攻击者 工作稍微辛苦一点；而不是 坐在你和服务器之间 攻击者使用数据包嗅探器 实际上必须破坏路由器并且 开始修改返回的数据包 等等。但这还不是全部 比仅仅嗅要困难得多；和 没有主机密钥检查，它将继续 完全未被客户发现或 服务器。
他显然是在谈论 MITM 攻击，而不是服务器身份验证。我认为使用互锁协议将明显防止 Putty FAQ 中提到的攻击，但我仍然不明白他们为什么不使用它。
It seems that the SSH designers cared a great deal about man in the middle attack.
Their approach was, to save server's public key finger print at the first time you're connected to the server (and hope that the user doesn't connect from a poisoned network in the first time, for instance if he has a virus in the computer). The user then uses the fingerprint to verify the server's public key next time he'll connect to this server.
In practice, I found out that many user simply ignores warnings about unmatched fingerprints, and assume it's due to server re-installation. It's just MITM attack is so difficult to conduct and rare, you never worry about it. Moreover, many times a user wants to use ssh many different computers, and he wouldn't bother importing all the fingerprints to any computer he might want to use SSH with (hey, can you look why my site is down, I'm panicked! I'm not in the office, I'll drop to the nearest internet cafe and have a look).
To be fair, one can use DNSSEC and use the DNS servers as the CA. However I never saw that used in practice. And anyhow, it's not a mandatory part of the protocol.
Many years I thought one cannot avoid MITM without preshared secret, but I've been recently reading Bruce Schneir's excellent "Practical Cryptography", there he mentions the interlock protocol.
- Alice sends Bob her public key.
- Bob sends Alice his public key.
- Alice encrypt her message using Bob's public key. She sends half of the encrypted message to Bob.
- Bob encrypts his message using Alice's public key. He sends half of the encrypted message to Alice.
- Alice sends the other half of her encrypted message to Bob.
- Bob puts the two halves of Alice's message together and decrypts it with his private key. Bob sends the other half of his encrypted message to Alice.
- Alice puts the two halves of Bob's message together and decrypts it with her private key.
Now, Mallory has to send something to Bob in step (3) of the protocol, after he receives half of Alice's message, even though he can't decrypt it until he gets everything from Alice in (5). He must fabricate a message to Bob, and Bob is likely to notice he's fabricating, say, after he ls his home directory.
Why didn't SSH use such a scheme? It seems to really fit its goals. It doesn't require any other entity, and it makes MITM attacks substantially more difficult.
Is it something inherent? A flaw in my understanding of the problem? Or just the designer thought the extra security doesn't worth complicating the protocol?
PS:
If you think that it would cause too much overhead, you can force the users of the protocol to use interlock only for the first 10K of data in the connection, so in practice it wouldn't matter too much, but MITM would be more difficult never the less.
Update:
The attack on the interlock protocol described here, does not mean a MITM attack is possible, it does mean that if a single password is sent during the communication the MITM can intercept it and the user would only see a time out error.
Update 2:
The point Eugene, raise is valid. The interlock protocol doesn't allow authentication. That is, you still can't be sure that if you're connecting to example.com, it is indeed example.com, and not malicious.com impersonating to example.com. You can't know that for sure without, say, DNSSEC. So for example, if you're SSHing to the missles silos, and write launch_missile -time now (without, say, using ls to verify the server is indeed the server in the missiles silos), it might be that you actually wrote that in a malicious server, and now the enemy know you're about to launch missiles against him. This type of attack indeed won't be prevented by the interlock protocol.
However if I understand the protocol correctly, a much more dangerous attack, and very practical attack, might be prevented. If the interlock protocol is used, even if you don't know anything about example.com, it is impossible that you would SSH to your server, and someone would eavesdrop to the entire SSH session. I think that this type of attack is much more likely.
Maybe SSH don't care about MITM attack? I think not, see for instance Putty FAQ:
Those annoying host key prompts are
the whole point of SSH. Without them,
all the cryptographic technology SSH
uses to secure your session is doing
nothing more than making an attacker's
job slightly harder; instead of
sitting between you and the server
with a packet sniffer, the attacker
must actually subvert a router and
start modifying the packets going back
and forth. But that's not all that
much harder than just sniffing; and
without host key checking, it will go
completely undetected by client or
server.
He's clearly talking about MITM attack and not about server authentication. I think using the interlock protocol will clearly prevent the attack mentioned in the Putty FAQ and I still don't understand why didn't they use it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不明白互锁协议如何防止 MITM。
问题不在于如何交换密钥，而在于如何信任它们。您正确地指出，人们会忽略密钥不匹配的警告。这确实是最大的缺陷，但是您描述的协议并没有解决密钥来源的验证问题。 SSL 使用 X.509 证书和 PKI 来验证信任。 SSH也可以使用证书，但几乎没有SSH软件支持它们。
I don't see how interlock protocol prevents MITM.
The problem is not how to exchange keys, but how to trust them. You correctly point out, that people ignore warnings that the keys don't match. This is really the biggest flaw, but the protocol you describe doesn't solve the problem of verification of key origin. SSL uses X.509 certificates and PKI to verify trust. SSH can also use certificates, but almost no SSH software supports them.