成千上万的网站和个人依靠SSL来保护敏感信息的传输，比如密码、信用卡信息和那些期望通过加密来保障隐私的个人信息。然而，最近被泄密的文件表明，美国国家安全局NSA记录了庞大的互联网流量并且保留其中的加密信息供以后解密分析。想监控互联网加密流量的政府远不止美国一个，沙特阿拉伯曾就SSL流量解密寻求过帮助，中国在今年一月份被指控对GitHub进行基于SSL的中间人攻击，伊朗也被报道进行深度包检测，但这些仅仅是冰山一角。
政府会考虑花大代价来记录和存储大量的加密流量,是因为如果用于流量加密的SSL私钥将来可以获得—可能是通过法律途径,社会工程学,成功攻破了网站,亦或通过加密分析，那么所有这些网站的历史流量会被瞬间解密。跟打开潘多拉魔盒一样,作为一个点击率高的站点,使用单一的密钥就可以解密过去数以百万人所加密过的流量。
有一个抵御的方法,那就是著名的完美转发密钥(PFS)。PFS采用即使主密钥被泄露每个临时会话密钥也不会被泄露的方式连接SSL站点，所以当使用PFS的时候,一个SSL站点私钥的泄漏不一定会暴露网站过去通信内容。PFS的安全在于双方会话结束后丢弃共享密钥(或经过一段适当时期后恢复会话)。
窃听者想解密使用PFS的通信内容会面临一个很艰巨的任务：每一个初始会话需要单独攻击。仅仅知道主密钥而不知道临时会话密钥对数据解密没有任何帮助。相反，当SSL连接没有使用PFS的时候，用于加密后续会话通信的密钥由SSL站点生成,而发送数据采用长期的公-私密钥对。如果这个主密钥被泄露，所有之前的加密会话很容易被解密。
PFS发明于1992年，比SSL协议早两年诞生,一个理想的结果是希望SSL一开始就能使用PFS。然而,近20年后,大多数的SSL站点还没有使用PFS。
PFS的使用依赖于浏览器和web服务器成功协商一个共同支持的PFS加密套件。如若可能，当PFS协商有利于浏览器用户群体隐私时希望浏览器能提供所有它支持的PFS加密套件列表，另外存在的一个比较严重的PFS性能缺陷是需要在服务器端进行大范围的查找工作。另一方面,只有少数浏览器被广泛使用,如果政府为了更容易解密那些加密通信流量，它们会发挥其能限制PFS的使用，那么将会从限制web浏览器流行的数量开始。
浏览器对PFS的支持现状
Netcraft公司选了5个主流浏览器(IE、谷歌、火狐、Safari和Opera)，用 Netcraft公司六月份“SSL调查”所获得的240万个SSL站点来测试这五个浏览器对PFS的支持情况。结果显示它们对PFS的支持差异显著:IE自带PFS的SSL连接操作只有很小一部分,然而,谷歌、Opera和火狐接近三分之一的SSL连接被PFS保护，Safari仅仅比IE好一点。具体结果如图所示：
图中加密套件来自每个浏览器与240万个SSL站点连接时采用的，Opera的数据不包含它的TLS1.2加密套件。
IE确实比较薄弱因为它不支持任何同时使用RSA公钥和非椭圆曲线DH密钥交换的加密套件，而这两种是PFS加密套件里最受欢迎的。IE支持比最常规使用的PFS加密套件优先级低的非PFS加密套件。说来也奇怪，IE居然支持采用罕见的DSS认证方法的DHE-DSS-AES256-SHA加密套件而不是很流行的DHE-RSA-AES256-SHA加密套件。
IE10的加密套件列表和在Netcraft的“SSL调查”中实际协商的加密套件。其中属PFS的加密套件在表中用绿色加粗字体显示。
Safari浏览器支持较多的PFS加密套件，但是非椭圆曲线加密套件只是备用。当几个非PFS加密套件有一个较高的权限时，web服务器为了顾及到浏览器的性能最终将选择一个非PFS加密套件，即使web服务器自己支持某些(非椭圆曲线)PFS加密套件。
谷歌、火狐和Opera这三种浏览器支持PFS的效果比较好，在任意给定的优先级前更倾向于选择PFS加密套件而不是非PFS加密，比如，Opera浏览器的性能列表抬头标明：DHE-RSA-AES256-SHA, DHE-DSS-AES256-SHA, AES256-SHA, DHE-RSA-AES128-SHA, DHE-DSS-AES128-SHA, AES128-SHA。Netcraft公司的测试仅仅包含了Opera浏览器的加密套件列表里现存的TLS1.2的加密套件，因此Opera浏览器实际使用PFS的SSL站点多于图表中显示的结果。
这些浏览器都没有明显的改变它们的用户界面，只是用类似EV证书的绿色地址栏表示PFS的使用。谷歌浏览器和Opera浏览器用弹出框或对话框显示使用的加密套件，使用用户能理解的自然语言显示，比如“[..]ECDHE_RSA作为密钥交换机制”。
Web服务器对PFS的支持情况
尽管浏览器尽力选择PFS加密套件，但是具体使用哪种密钥交换算法是由服务器决定的，服务器可能不支持任何的PFS，又或者选择一个可以替代的加密套件(可能考虑到性能的问题)。使用Diffie-Hellman密钥交换算法是以牺牲服务器的性能为代价的，因为它需要一个额外的算法来产生密钥。
用几个浏览器的密钥组的性能进行排序，在Netcraft公司的“SSL调查”中至少有三分之二的SSL连接都没有用PFS加密套件。测试结果如图所示：
服务器对SSL站点的支持情况：每个浏览器分别与“SSL调查”中的240万个SSL站点通信，按web服务器供应商分类。
Nginx是最初由俄罗斯人Igor Sysoev写的一个开源web服务器，默认使用强加密套件，在nginx的SSL性能文档里有一些说明。除了IE和Safari，超过70%的SSL站点用nginx web服务器时选择使用PFS加密套件与浏览器通信。
在使用Apache服务器的SSL站点中频繁使用PFS，大约三分之二的SSL站点在使用火狐、谷歌或者Opera访问时都使用PFS加密套件。相反，微软在Apache服务器上对PFS的支持明显欠缺，微软的IIS和IE都很少用PFS加密套件，在IE与IIS之间使用PFS加密套件的SSL站点仅有0.01% 。
谷歌对一些自己的SSL站点采用PFS加密套件，但是好像托管在Google App Engine上的一些SSL站点并没有使用PFS加密套件。
SSL与棱镜计划有什么关系?
与棱镜计划相关公司使用PFS情况列表：PFS加密套件用绿色加粗字体显示。
在棱镜计划受牵连的那些公司的SSL站点中，没有任何一家的主流浏览器都使用PFS加密套件。当然，谷歌确实在大多数浏览器里使用了PFS加密套件，但不包括Opera浏览器。据说棱镜计划采用检查SSL流量来运作,一直被认为十分不可能，因为报价需要花费2000万美金。如果美国国家安全局获得了这些网站的私钥，除了谷歌以外所有的SSL站点历史通信都将被解密。
其他一些著名的SSL站点
其他一些著名SSL站点使用加密套件情况：选中的SSL站点协商的加密套件，PFS加密套件在上用绿色加粗字体显示。
DuckDuckGo是一个搜索引擎，自爱德华·斯诺登披露它提倡使用匿名的隐私策略以来一直备受媒体关注。如果被DuckDuckGo用来加密的私钥被泄露—比如它们其中的一个服务器被攻破，那么之前所有的日志记录将被披露出来。DuckDuckGo也许是美国国安局特别感兴趣的一个目标，也许是因为它的用户量和流量相对于谷歌来讲比较少的原因。
CloudFlare使用了和谷歌用的ECDHE RC4或者AES类似的加密套件，但Opera浏览器例外。CloudFlare的SSL实现选项之一是从浏览器到CloudFlare服务器“灵活”的加密SSL流量，但如果内容不从缓存中返回，从CloudFlare连接到原来的网站将不使用SSL。相比试图解密加密的内容，去拦截CloudFlare和原来的网站之间的未加密的流量通信可能会更容易。
Mega没有用PFS加密套件，可能因为美国政府突然抄查Megaupload服务器的历史举动的原因。对服务器进行物理访问，不难想象任何服务器的私钥可能被摘录，即使它保存在非持久性存储器上。
总结
阴谋论者对下面的情况可能不会感到惊讶：
微软的IE、IIS和他们自己的一些web站点不使用PFS加密套件。苹果在Safari浏览器对PFS的支持仅仅比微软稍微好点。
俄罗斯是美国间谍的长期目标，也是nginx服务器(该web服务器经常使用PFS)的发源地。
几乎所有与棱镜计划相牵连的公司运行的web站点都没有使用PFS加密套件。
PFS没有普及的原因让阴谋论者津津乐道，其中一个原因可能是顾虑到网站的性能(善意的)：Mavrogiannopoulos报道称用DHE-RSA加密套件比用普通的RSA算法连接SSL站点网站性能降低3倍。由于在浏览器中没有清晰指出使用PFS加密套件，普通用户也不会注意到网站没有使用PFS加密套件，而如果网站的性能提高，普通用户是能够切身体会到的，所以普通的SSL站点会被说服放弃使用PFS提供的保护。
缺少了两大主流浏览器和大多数web站点的支持，互联网中大多数用户并未得到PFS的安全保护。没有PFS的保护，如果一个组织曾经被胁迫交出RSA私钥—合法的或以其他方式，那么所有过去的SSL通信将处于危险中。然而PFS也不是万能的，它使得对过去SSL通信的大规模解密变得困难的同时，也无法防止对单个会话的网络攻击。无论是否使用PFS， SSL仍然是web站点用来在互联网中安全传输数据防止窃听者的一个重要工具(也许是最完善的)。
应该注意的是美国政府以及许多其他政府，颁发一些他们中意的SSL证书–尽管冒着扰乱程序规则和被其他有警觉性的用户发现的危险，甚至谷歌的某些SSL站点。在主动攻击可以实现，并且不可能被检测到的状态下，更应该注意被动攻击窃听者是否有利用非PFS的空档。
关于PFS协商的一些细节
用于SSL站点链接的加密套件的选择由浏览器和SSL站点之间共同协商。浏览器和SSL站点都各自拥有自己所支持的SSL加密套件的优先级列表。在握手阶段，浏览器发送一个ClientHello消息给SSL站点，其中包含一个在优先级列表里提供的所有的加密套件列表。 SSL站点首先选择在收到的浏览器列表中自己也支持的浏览器列表中的第一个加密套件，或者忽略那个优先级顺序而选择在浏览器支持的自己列表中的第一个加密套件。如图3所示，无论是加密套件A(如果优先考虑浏览器的优先顺序)还是加密套件C(如果优先考虑web站点的优先顺序)用于作为连接的加密套件是由SSL站点的设置而定。
浏览器与服务器加密套件协商过程
选择加密套件算法介绍
Diffie-Hellman密钥交换( DH)和它的变种经常用来协商通信双方共享的临时会话密钥，密钥本身从未被发送。每个会话密钥在会话结束后被丢弃( 适当时期之后重新协商)。Diffie-Hellman的安全性依赖于离散对数问题的困难程度，即交换DH公钥的同时使窃听者难以确定具体的共享密钥。 SSL加密套件支持常规短暂的Diffie-Hellman密钥交换(通常称为EDH或DHE )和短暂的椭圆曲线的Diffie-Hellman ( ECDHE ) ，它采用了跟EDH类似的体系，依赖于椭圆曲线离散对数问题的难度。 ECDHE基于椭圆曲线的密钥交换，尽管速度更快，但只有少数SSL站点支持。
*本文来源于英国网络服务公司NETCRAFT，并由IDF实验室志愿者李秀烈翻译，土豆校对。
