最近,Diffie-Hellman中的一个新的漏洞(非正式地被称为“logjam”)已经发布, 本页面已经被整合在一起,提出了如何应对漏洞:
对于正确部署Diffie-Hellman for TLS,我们有三条build议:
- 禁用导出密码套件。 尽pipe现代浏览器不再支持导出套件,但FREAK和Logjam攻击允许一个中间人攻击者欺骗浏览器使用出口级encryption,之后可以解密TLS连接。 出口密码是1990年代政策的一个残余,它阻止了强大的密码协议从美国出口。 没有现代客户依赖出口套件,并且禁用它们几乎没有什么坏处。
- 部署(临时)椭圆曲线Diffie-Hellman(ECDHE)。 椭圆曲线Diffie-Hellman(ECDH)密钥交换避免了所有已知的可行的密码分析攻击,现代networking浏览器现在更喜欢ECDHE而不是原始的有限域Diffie-Hellman。 我们用来攻击标准Diffie-Hellman组的离散对数algorithm不像预计算那样强大,并且单个服务器不需要生成唯一的椭圆曲线。
- 生成强大而独特的Diffie Hellman组 。 数百万个服务器使用了一些固定的组,这使得它们成为预计算和潜在窃听的最佳目标。 pipe理员应该使用每个网站或服务器的“安全”素数生成独特的2048位或更强的Diffie-Hellman组。
根据上述build议,我应该采取哪些最佳实践步骤来保护我的服务器?
从您链接的文章中 ,有三个build议的步骤来保护自己免受此漏洞的攻击。 原则上这些步骤适用于您可能使用SSL / TLS的任何软件,但在这里我们将处理将它们应用到Apache(httpd)的具体步骤,因为这是所讨论的软件。
- 禁用导出密码套件
在下面的2.configuration变化中应该加以处理(在SSLCipherSuite
行尾附近的!EXPORT
是我们将如何禁用导出密码套件)
- 部署(Ephemeral)椭圆曲线Diffie-Hellman(ECDHE)
为此,您需要编辑Apacheconfiguration文件中的一些设置,即SSLProtocol
, SSLCipherSuite
, SSLHonorCipherOrder
以具有“最佳实践”设置。 像下面的东西就足够了:
SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA SSLHonorCipherOrder on
注意:至于要使用哪个SSLCipherSuite
设置,这是不断变化的,最好咨询一下这个资源来检查最新推荐的configuration。
3.生成强大而独特的Diffie Hellman组
为此,您可以运行
openssl dhparam -out dhparams.pem 2048
。
请注意,当服务器产生参数的时候,这会给服务器带来很大的负担 – 你可以通过在另一台机器上生成参数并使用scp
或类似的服务器将它们转移到服务器上使用,来解决这个潜在的问题。
要从Apache文档中使用这些在Apache中新生成的dhparams
:
要生成自定义DH参数,请使用openssl dhparam命令。 或者,可以将 RFC 2409的第6.2节中的以下标准1024位DH参数附加 到相应的SSLCertificateFile文件中 :
(重点是我的)
然后是一个标准的1024位DH参数。 由此我们可以推断,自定义生成的DH参数可以简单地附加到相关的SSLCertificateFile
中。
为此,请运行类似于以下内容的内容:
cat /path/to/custom/dhparam >> /path/to/sslcertfile
或者,根据最初链接的文章的Apache子部分 ,如果您不想更改证书文件本身,也可以指定您创build的自定义dhparams文件,因此:
SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"
无论哪个Apacheconfiguration与您的特定SSL / TLS实现相关 – 通常在conf.d/ssl.conf
或conf.d/vhosts.conf
但是这取决于您如何configurationApache。
值得注意的是,按照这个链接 ,
在Apache 2.4.7之前,DH参数始终设置为1024位,并且不是用户可configuration的。 这已经在mod_ssl 2.4.7中得到了修复,红帽已经用httpd-2.2.15-32.el6将其反向移植到他们的RHEL 6 Apache 2.2发行版中
在Debian上Wheezy将apache2升级到2.2.22-13 + deb7u4或更高版本,并将openssl升级到1.0.1e-2 + deb7u17。 上面的SSLCipherSuite不能完美的工作,而是根据这个博客使用以下内容:
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA
您应该检查您的Apache版本是否晚于这些版本号,具体取决于您的发行版,如果不是,请尽可能更新。
执行上述步骤更新configuration并重新启动Apache服务以应用更改后,应通过在SSLLabs上运行testing以及与此特定漏洞相关的文章 ,检查configuration是否符合要求。
基于一个Winni Neessen的补丁,我已经发布了Apache / 2.2.22(Debian Wheezy,也许还可以在Ubuntu上使用)的修复: https ://flo.sh/debian-wheezy-apache2-logjam-fix/ – thx 。 为您的反馈。
不要去复杂的路线上面的黑客,考虑切换到您的主要networking服务器软件(不只是caching或代理)的nginx 。 显然,现在的标准看起来比旧的apache引擎更安全。 通过使用nginx存储库,它为您提供了一种比apache更稳定的web服务器引擎。
我完全切换。 为我节省了很多关于TLS的耗时问题,而且 – 对于我们的configuration – 同时也释放了大量的RAM。 事实上,相比于我习以为常的httpd / apache的大量configuration复杂性,我发现nginx的工作非常简单直接。 可能是一个味道的问题,我转身之前,已经变得很stream畅的httpd / apache重写/configuration/维护,这比我担心会更容易。 最近有关于nginx config的最新信息可以在线获得,而且它的用户基础非常庞大,非常活跃并且支持友好。 https://news.netcraft.com/wp-content/uploads/2017/03/wpid-wss-top-1m-share.png