本文向你们展示如何在nginx的web服务器上设置更强的SSL。我们是通过使SSL无效来减弱CRIME攻击的这种方法实现。不使用在协议中易受攻击的SSLv3以及以下版本并且我们会设置一个更强的密码套件为了在可能的情况下能够实现Forward Secrecy,同时我们还启用HSTS和HPKP。这样我们就有了一个更强、不过时的SSL配置并且我们在Qually Labs SSL 测试中得到了A等级。
[b]我们在nginx的设置文档中如下编辑[/b]
[url=https://www.smacktls.com/]INRIA, Microsoft Research and IMDEA[/url]所发现的一种中间人攻击。FREAK就是“Factoring RSA-EXPORT Keys .”。这种攻击可以追溯到90世纪90年代,也就是在美国政府禁止出售加密软件到海外的时候,除非输出的密码套件中加密密钥的长度不超过512位。
被证明是一些先进的TLS客户端-包括苹果的SecureTransport和OpenSSL-有一个Bug在里面。这个Bug造成了它们接受了RSA密钥的输出等级甚至当客户端都不要求RSA的密钥输出等级。这个Bug造成的影响还是相当严重的:假如客户端是易受攻击的并且服务器支持输出RSA,它允许第三人通过一个活跃的攻击者来减弱连接的质量进行攻击。
这里是两部分服务器必须接受的“RSA输出等级”攻击。
MITM攻击过成如下:
[list]
[*] 在客户端的Hello消息中,它请求一个标准的“RSA”密码套件。[/*]
[*] MITM攻击者改变这个消息为了得到“RSA的输出”.[/*]
[*] 服务器返回一个512位的RSA输出密钥,并用它的永久密钥签名。[/*]
[*] 由于OpenSSL和SecureTransport存有bug,客户端就接受了这个弱密钥。[/*]
[*] 攻击者分析RSA模块为了恢复正在通信时RSA的解密密钥。[/*]
[*] 当客户端把加密的“预备主密钥”发送给服务器时,攻击者现在可以解密它从而得到TLS的“主密钥”。[/*]
[*] 从现在起,攻击者就可以看到明文了,并且可以注入任何他想的东西。[/*]
[/list]
这个页面上提供密码套件但是支持密码输出等级。确保你的OpenSSl是最近更新过的版本而且你的客户端也要使用最新的软件。
[b]Heartbleed(心脏出血)[/b]
Hearbleed是一个在2014年四月OpenSSL密码库里被发现的安全漏洞,它被广泛用在运输层(TLS)协议的实施中。Heartbleed可能被使用不管是否使用了一个易受攻击的OpenSSL,比如说在一个服务器或者客户端使用。它是在DTLS心跳扩展(RFC6520)由不合适的输入确认(因为没有边界检查)所造成,因此这个漏洞的名字为“心跳”.这个漏洞被划为一个重读的缓冲区,更多超出允许的数据被读出。
哪些版本的OpenSSL被Heartbleed影响?
不同版本的情况:
[list]
[*] OpenSSL 1.0.1 到 1.0.1f (包括) 受攻击。[/*]
[*] OpenSSL 1.0.1g不受攻击。[/*]
[*] OpenSSL 1.0.0的分支不受攻击。[/*]
[*] OpenSSL 0.9.8 的分支不受攻击。[/*]
[/list]
OpenSSL在2011年12月发现这个漏洞而且在2012年3月14日发布OpenSSL1.0.1之前一直没有采取措施。2014年4月7号发布的OpenSSL1.0.1g修复了这个漏洞。
通过更新OpenSSL就可以免受这个漏洞带来的攻击。
[b]SSL 压缩(犯罪攻击)[/b]
通常来说,犯罪攻击使用 SSL 压缩来施展它的魔法。SSL 压缩在 nginx1.1.6+/1.0.9+ 中默认是关闭的(如果使用 openssl 1.0.0+).
如果你正在使用 nginx 或者 OpenSSL 其他早期版本,并且你的发行版并没有回迁此选项,那么你需要重新编译不支持 ZLIB 的 OpenSSL。这将禁止使用DEFLATE压缩方法来使用 OpenSSL。如果你这样做,那么你仍然可以使用常规的HTML DEFLATE压缩。
[b]SSLV2 与 SSLv3[/b]
SSL v2 并不安全,因此我们需要禁用它。我们也可以禁用 SSL v3,当 TLS 1.0 遭受一个降级攻击时,可以允许一个攻击者强迫使用 SSL v3 来连接,因此禁用“向前保密”。
再次编辑此配置文件:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
贵宾犬攻击和TLS-FALLBACK-SCSV
SSLv3允许利用“[url=https://raymii.org/s/articles/Check_servers_for_the_Poodle_bug.html]贵宾犬 POODLE”漏洞[/url],这是禁用它的一个主要原因。Google已经提议一种叫[url=https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00]TLSFALLBACKSCSV[/url]的SSL/TLS的拓展,旨在防止强制SSL降级。以下是升级后自动启用的OpenSSL版本:
[list]
[*] OpenSSL 1.0.1 有 TLSFALLBACKSCSV 在 1.0.1j 及更高的版本.[/*]
[*] OpenSSL 1.0.0 有 TLSFALLBACKSCSV 在 1.0.0o 及更高的版本.[/*]
[*] OpenSSL 0.9.8 有 TLSFALLBACKSCSV 在 0.9.8zc 及更高的版本.[/*]
[/list]
[url=http://wiki.nginx.org/HttpSslModule#ssl_protocols]更多的信息请参阅NGINX文档[/url]
[b]密码套件[/b]
Forward Secrecy 确保了在永久密钥被泄漏的事件中,会话密钥的完整性。PFS 实现这些是通过执行推导每个会话的新密钥来完成。
这意味着当私有密钥被泄露不能用来解密SSL流量记录。
密码套件提供 Perfect Forward Secrecy 暂时使用 Diffie-Hellman 密钥交换的形式。他们的缺点是开销大,这可以通过使用椭圆曲线的变异的改进。
我建议以下两个密码套件,后者来自 Mozilla 基金会。
推荐的密码套件:
[url=https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security]HTTP Strict Transport Security (HSTS)[/url] ,它指示浏览器只通过HTTPS来访问你的站点。
[b]HTTP Public Key Pinning Extension[/b]
你同样应该开启 [url=https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning]HTTP Public Key Pinning Extension[/url]。
Public Key Pinning 意味着证书链必须包含处于白名单之中的公钥。它确保只在白名单中的CA可以对*.example.com进行签名,而不是浏览器中保存的任何一个CA。
我已经写了关于它的一篇文章,包含背景理论和配置实例,针对 Apache, Lighttpd 以及 NGINX:https://raymii.org/s/articles/HTTPPublicKeyPinningExtension_HPKP.html
[b]配置示例
[/b]
[url=https://www.ssllabs.com/ssltest/]SSL 实验室测试(SSL Labs tes)[/url]看看你是否得到一个漂亮的A。同时,当然,拥有一个安全的,牢靠的,作为未来样例的SSL配置。