SSL 中的 PFS 意味着服务器为每个新会话执行 Diffie-Hellman 密钥交换和签名，因此与非 PFS 密码套件相比，服务器上握手的 CPU 成本大约翻了一番。但是很少有握手 CPU 成本是不可忽略的（打开多个连接的客户端使用仅使用对称加密的缩写握手，并且基本 PC 有足够的能力使用单个 CPU 处理每秒数百次完整的握手核）。我建议做一个上下文基准。

仍然使用 SSL，没有定义的 PFS-able 密码套件也支持 RC4 加密。除此之外，当前部署的所有非考古 Web 浏览器都将接受“DHE”密码套件（产生 PFS），因此这里不存在互操作性问题；问题在于您是否想要 RC4：您必须平衡对不可告人的密钥妥协（针对 PFS 增加了一些保护）的恐惧与对选择密文攻击（即 BEAST，RC4 密码套件似乎免疫）的恐惧。

操作系统或负载平衡器可能会报告密码套件统计信息，但我不会打赌。您可以使用OpenSSL（命令行可执行文件，使用s_client命令）进行测试。您还可以使用任何体面的协议分析器，例如Wireshark，它可以告诉您在给定连接上使用了哪个密码套件（密码套件标识符作为握手的初始步骤的一部分“以明文形式”发送，因此很容易用嗅探器抓住它）。

互操作性在过去是一个问题，尤其是在 ipsec 中。SSL 稍微容易一些，但并非所有客户端都支持它。如果我想检查我的流量，我可能会在跨端口上进行 tcpdump 并编写一个脚本来查找握手中接受的密码套件，假设我们正在谈论 SSL。

在实施之前，我应该注意哪些陷阱或常见错误？任何管理、特定于实现或特定于平台的内容？脑海中浮现出一些。

前向保密 TLS 中使用了两种密钥交换算法。DHE 和 ECDHE。要与最广泛的客户保持保密，您需要同时支持两者。通常，您应该优先选择 ECDHE 而不是 DHE，因为它性能更好并且与 Java 7 兼容（见下文）。

强制前向保密将排除 Windows XP 上的 Internet Explorer（任何版本）。我希望在 XP 上使用 SSL/TLS 堆栈中内置的窗口的任何东西都是如此。

对于 DHE，您需要确保使用强 dh 参数。您应该使用具有至少 2048 位素数的自定义生成的 dh 参数（dh 素数的安全性与相同长度的 RSA 密钥相当）。

如果您协商 DHE 密码套件并使用大于 1024 位的 DH 参数，Java 6 和 7 就会中断。这是 java 6 的一个特别严重的问题，因为它不支持 ECDHE。

在我们的服务器上强制执行 PFS 之前，我想对不兼容性进行说明并做好准备。

一种选择可能是使前向保密密码套件成为首选但不是强制性的，并设置您的服务器以记录每个连接使用的密码套件。然后，您可以查看您的日志并确定如果您强制执行前向保密，您将失去多少客户。

对 PFS 能做什么和不能做什么有误解吗？我们的审计部门是否需要进行现实检查？

基本上，前向保密的作用是防止有人窃取您的密钥，使用它来被动解密流量。特别是在没有前向保密的情况下，一直在监控和存储您的流量并随后窃取您的密钥的人可以返回并解密他们之前捕获的流量。

前向保密不会做的是防止窃取您的密钥的人使用它来冒充您（并且充当中间人或用他们的服务器替换您的服务器）。

如果对称加密被破坏，前向保密将无济于事。用于前向保密密钥交换的密码学也可能被破坏（请参阅有关上述 dh 参数的评论）。

PFS 的好处是否受到应用程序的限制？（网络与 smtp 等）

好处是相同的，但您可能会发现客户的支持并不常见。