严格来说，不，相互认证并不能防止 POODLE。不过，一些细节可能很重要。

POODLE 攻击的核心是有一种方法，使用 SSL 3.0，可以更改一些记录，以便接收端不会注意到概率为 1/256 的替换。使用此协议的错误功能，攻击者可以“尝试”对加密数据的单个字节进行解密猜测，并以 1/256 的概率获知该字节。但是，在失败时，接收端会及时注意到问题，并且连接会中断。这里重要的一点是，握手细节不会以任何方式影响这些。基于证书的客户端身份验证不会使该协议问题消失。

POODLE 的经典、基于 Web 的描述随后将该问题应用于 Web 上下文，即：

• 目标是一个 HTTP cookie。
• 攻击者通过一些邪恶的 Javascript 或其他 URL 注入方法，使受害者反复向某个服务器发出请求，所有请求中都包含目标 cookie。
• 攻击者不仅可以触发请求，还可以捕获任何错误，因此断开的连接不会显示在粗心的受害者的屏幕上。

在这种情况下，POODLE 恢复目标 cookie，每个猜测的字节平均有 128 个连接（假设 cookie 字节是可打印的 ASCII 字符，这个数字可以稍微降低）。

在您的情况下，客户端应用程序可能不是 Web 浏览器，因此，攻击者可能难以触发重复连接。此外，如果您使用证书进行相互身份验证，那么您可能没有大的会话 cookie，从而删除了一个多汁的目标。尽管如此，如果攻击者接受破坏他们尝试猜测的大多数连接，他们仍然可以试试运气并猜测一些字节。攻击者是否可以谨慎地实现这一目标实际上取决于应用程序在连接中断时的行为方式。特别是，如果执行 HTTP“保持活动”（如 SOAP-over-HTTP-over-SSL 的惯例），则客户端期望一些请求失败（因为服务器失去耐心并关闭了连接）并静默重启它们，因此攻击者很可能会静默猜测。

需要注意的是，POODLE 是关于机密性破坏，而不是完整性破坏。如果您只使用 SSL 以便对数据进行身份验证，但没有通过 SSL 隧道发送任何真正机密的内容，那么 POODLE 就不再是一个问题。

总结：为 POODLE 提供缓解的不是客户端证书；可以提供缓解的是客户端不是 Web 浏览器。但是，协议漏洞仍然存在并且可能仍然可以利用，具体取决于您的应用程序协议的详细信息。

您真的应该考虑更新这些客户端应用程序。通过保持 SSL 3.0 处于活动状态，您正在寻找麻烦。