使用公钥/私钥对（RSA）时，建议使用哪些技术来防止 MITM 攻击？

Question

我目前有一组 Web 服务，它们向各种不同的客户端类型和角色公开接口。身份验证通过公钥/私钥对 (RSA) 进行处理，仅用于验证 HTTP 标头中作为签名的 URL。

此时 HTTP 主体未加密（我使用 2048 位私钥/公钥，这只允许我加密少量信息），因此 RSA 不够安全，因为服务器无法再向自己证明没有中间人。我也可以加密 HTTP 主体，但是性能怎么样？

我的问题是：在这种情况下，建议使用哪些技术来防止 MITM 攻击？

Answer 1

有绝对没有意义如果您不加密整个经过身份验证的会话，则使用 HTTPS 是错误的。如果您在任何时候通过不安全的通道传输会话 ID，那么攻击者可以使用它来进行身份验证（例如 Firesheep）。此外，您违反了OWASP a9。

从性能角度来看，SSL 最耗时的部分是初始握手。此过程会被缓存，并且每个客户端仅执行一次。

还有一件事要记住，如果你想停止SSL条风格攻击，那么你应该设置STS 报头。

Answer 2

如果您的目标仅仅是真实性（而不是机密性），则可以使用来自客户端或服务器或两个方向的标头中的签名来验证收到的位来自发送方。

请注意，如果签名的内容没有经过检查的时间戳，则很容易受到简单重放的攻击，这可能使中间人能够执行某些功能或无限期地伪装成另一方。

“数据对于密钥大小来说太大”的错误部分是由于直接 RSA 加密/解密需要大量计算，因此实现并非设计用于处理大量数据。实际限制与算法提供的加密强度保证有关。允许较大的低熵有效载荷会削弱它。

为了避免此错误，您需要使用消息摘要算法，该算法对较大的一组位（例如 HTTP POST 正文）执行单向哈希（如 MD5），然后使用 RSA 加密对固定大小的摘要结果进行加密。加密的哈希本质上是数字签名。然后，接收方解密，计算正文的哈希结果，并比较哈希以验证签名。

请注意，如果由于使用了加密而导致会话密钥可用，则可以使用共享对称密钥对正文的哈希值进行加密，而不必进行成本更高的 RSA 加密。这称为消息认证码 (MAC)，其强度不如签名。

Answer 3

寻求经过尝试和验证的解决方案：使用 HTTPS 进行相互身份验证，作为额外加密整个会话。除非您的客户端在 TI 计算器上运行，否则 HTTPS 性能不是问题。Google 将其用于整个 Gmail，这应该是一个很好的例子。