SSL信息随着无数网络“窃听风云”事件的曝光，SSL/TLS的一个不起眼的特性忽然引起了人们的兴趣，它叫做正向保密。那么它到底是什么，为什么现在引起这么多关注？
会话密钥的生成和交换
每个SSL连接都开始于一次握手，期间双方将自己的性能数据传递给对方，并进行密钥认证，然后就会话密钥达成一致。会话密钥被用于加密对话（会话）的其余部分，也可能会扩大到多个连接。随后会话密钥会被删除。密钥交换阶段的目的是确保通信双方就密钥进行安全可靠的磋商。换句话说，是为了避免其他人获得这些密钥。
有几种不同的密钥交换机制存在，但迄今为止应用最广泛的机制是基于RSA算法的。在这种机制中，服务器的私钥被用来保护会话密钥。这是一种很高效的密钥交换方法，但却有一个很大的副作用：任何取得服务器私钥拷贝访问权限的人都可以找到会话密钥并解密整个对话。
但在某些特定的情况下，副作用反倒成了好事。比方说，当给定了服务器私钥时，很多网络安全设备可以对通信进行解密（并能对通信内容进行检查）。如果没有这个能力，被动IDS/IPS和WAF设备就不能得到通信内容，也就无法提供保护。
当你的流量被大规模监控时，RSA密钥交换便成为了一件相当严肃的事情。攻击者现在可能没有你的私钥，但他们能记录下你的所有加密通信。最终，他们可能会通过某种方式（如收买某些人获得担保或等到技术进步到一定程度时再破解密钥）得到密钥，而那时他们就能破解所有的信息。
Diffie–Hellman密钥交换
对基于RSA的密钥交换来说，还有一个选择是使用Diffie-Hellman算法，这种算法较慢，但会生成只能由通信双方获得的会话密钥。其他任何人都无法获得，即使他们有服务器私钥的访问权限。见注释(1)
当会话完成后，双方会销毁会话密钥，唯一能对通信进行解密的方法是破解会话密钥本身。这一协议特性被称为正向保密。见注释(2)
现在，破解会话密钥本身的难度显然要大大高于获取服务器私钥（特别是如果你通过担保获得的话）。而且，为了破解整个通信，你不能再仅仅获得一个（服务器的）密钥，而必须去破解属于每一次单独对话的会话密钥。
SSL与正向保密
SSL以两种算法支持正向保密，一种是标准Diffie-Hellman (DHE)算法，另一种是Elliptic Curve 加密算法 (ECDHE)的适用版本。但为什么不是每个人都在使用呢？
假设现在我们已有足够的兴趣和能力来配置正向保密，仍然会有两个障碍：
- DHE速度明显较慢。因此，网站操作人员为了提高性能倾向于关闭DHE组件。而且，不是所有的浏览器都支持全部必要的组件。如IE9和IE10只能通过与陈旧的DSA密钥配合来支持DHE。
- ECDHE速度也较慢，但比DHE要好一些。（Vincent Bernat发布过一篇博客，是关于ECDHE对性能的影响的，但他也警告说2011年以来情况可能有所变化。）然而，ECDHE 算法出现较晚，并未被广泛支持。例如，OpenSSL最近才在其1.x版本中加入对ECDHE的支持。
如果你既愿意支持ECDHE，又愿意支持DHE，那么你很可能在所有客户端上都支持正向保密。而所有主要的现代浏览器都只支持ECDHE，这意味着在仅有ECDHE 的情况下你也能够保护你的用户基础。决定做什么完全取决于你。例如，谷歌的网站倾向于在他们的配置中排除任何DHE组件。
如何配置正向保密
启用正向保密需要以下两步：
1.配置你的服务器，以灵活地从SSL客户端提供的列表中选择最理想的组件。
2.将ECDHE 和 DHE组件置于你的列表顶端。（顺序很重要，因为ECDHE组件更快，只要客户端支持，你肯定愿意用它。）
弄清楚需要启用哪些组件并把他们置顶是需要慎重对待的，因为不是所有浏览器（设备）都支持全部的正向保密组件。此时，你可能需要从那些已支持正向保密的网站（如谷歌）中寻找灵感。
简言之，下面是一些你可能想要启用并置顶的组件：见注释(3)
- TLS_ECDHE_RSA_WITH_RC4_128_SHA [已更新] RC4不再推荐
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
为使这一过程更简单，我采用了模拟握手。它可以了解主要浏览器的性能并决定就哪些组件进行协商，然后告诉你协商一致的组件是否支持正向保密。
这是该特性的一个活动中的截图：
正确使用它时，会在顶端的摘要部分出现一个明显提示：
“试验：该服务器对现代浏览器支持正向保密。”
可供选择的攻击载体
尽管Diffie-Hellman密钥交换的应用消除了大部分攻击载体，但那些强大的对手仍有其他攻击手段。例如，他们可以说服服务器操作人员记录下所有会话密钥。
服务器端会话管理机制也可能影响正向保密。由于性能方面的原因，在对话终止后，会话密钥可能还会被保存几个小时（甚至更久）。
此外，还有一种会话管理机制，叫做会话票证。它使用单独加密的密钥，这些密钥很少更换（在一些极端情况下，可能永远不会更换）。除非你对你的会话票证的执行情况十分了解，否则最好不要启用这一特性，以确保它不会危及正向保密。
注释：
(1)某些有着服务器私钥访问权限的人当然能够实施中间人攻击并模拟服务器。但只有当通信发生时他们才能这么做。把加密的通信内容大量积累下来随后再进行解密是不可能的。
(2)这一特性有时候也叫做完全正向保密，但因为可以通过破解会话密钥来对通信进行解密，显然它并不完美。
(3)在此我假设的是最普通的情况，也就是你有一个RSA密钥（实际上每个人都有）。如果你使用一个ECDSA密钥的话，那么需要启用很多ECDHE组件。我暂且将GCM组件忽略，因为其并未被广泛支持。同时，我也没考虑任何试图通过支持RC4而减弱BEAST攻击的潜在可能，因为这对几乎所有客户端设备都难以实现。
本文于2013年6月25日由 Ivan Ristic 发表于SSL Labs。