在Universal 2nd Factor (U2F) Overview的第 6 节中，讨论了 MITM 攻击——在该节的末尾，它写道：

It is still possible to MITM a user's authentication to a site if the MITM is 

a. able to get a server cert for the actual origin name issued by a valid CA, and 
b. ChannelIDs are NOT supported by the browser. 

But this is quite a high bar. 

我不相信这是一个如此高的标准。我们已经看到了很多攻击者能够获得虚假但受信任的 CA 签名证书的案例。而且，TLS ChannelID 并没有被大多数浏览器和服务器广泛采用（事实上，RFC 草案提案在 2013 年就已经过期）。此外，即使两个端点都支持 TLS ChannelID，活跃的 MITM 攻击者也可以在 ClientHello 消息期间通过降级攻击来阻止 TLS ChannelID 被使用。

我赞赏 FIDO 为减少我们对密码的依赖、使身份验证更安全、对用户来说更不麻烦而取得的飞跃。但是，它似乎在防止 MITM 攻击方面做得很少，攻击者能够获得假但受信任的证书，我们必须继续完全相信和信任 CA，它有让我们失望的历史。当然，如果连接可以被活跃的 MITM 攻击者破坏，即使是最安全的身份验证协议也是无用的。

其他基于密钥的身份验证协议（例如 SSH）通过内置在协议中的公钥固定来防止 MITM 攻击。例如，使用 SSH 时，客户端会存储它们连接的服务器的公钥。在建立连接之后，在密钥交换期间和尝试任何客户端身份验证之前 - 客户端通过检查服务器使用的公钥是否与文件中的公钥相同来验证它确实连接到预期的服务器对于该服务器，并确保服务器通过一些需要私钥的加密操作拥有与公钥相关联的私钥。

当然，HPKP（没有 FIDO）可用于在浏览器中固定站点的 SSL/TLS 证书，但这有其自身的问题。

我很好奇为什么 FIDO UAF 和 U2F 的架构师没有将协议更进一步，而是在协议中嵌入了一种公钥固定方法（可能使用与用于 SSL/TLS 连接的密钥对不同的密钥对），所以客户端可以确保他们在尝试进行身份验证之前连接到合法服务器，例如 SSH。有人愿意假设吗？