Nginx服务器中关于SSL的安全配置详解

 本文向你们展示如何在nginx的web服务器上设置更强的ssl。我们是通过使ssl无效来减弱crime攻击的这种方法实现。不使用在协议中易受攻击的sslv3以及以下版本并且我们会设置一个更强的密码套件为了在可能的情况下能够实现forward secrecy，同时我们还启用hsts和hpkp。这样我们就有了一个更强、不过时的ssl配置并且我们在qually labs ssl 测试中得到了a等级。

我们在nginx的设置文档中如下编辑

/etc/nginx/sited-enabled/yoursite.com (on ubuntu/debian)

或者在

/etc/nginx/conf.d/nginx.conf (on rhel/centos).

对于整个说明文档，你需要编辑服务器配置的服务器那块和443端口（ssl配置）。在说明文档的最后，你会发现实现了样例的配置。

确保在编辑之前做了备份！

beast攻击和rc4算法

简言之，就是通过篡改加密算法cbc密码块的加密模式，部分加密流量可以被偷偷地解密。更多的信息请参照以上链接。

新版本的浏览器客户端可以缓解bease攻击。建议禁用所有的tls 1.0密码并且只是用rc4。然而，[rc4有一个不断增加的列表来防止攻击]，(http://www.isg.rhul.ac.uk/tls/)其中的很多都将理论和现实交叉在一起。而且，这就是为什么nsa已经破解了rc4，他们所谓的“重大的突破”。

禁用rc4有几个结果。一、使用差劲儿浏览器的用户将使用3des来代替。3-des比rc4更安全。但是就意味着更加昂贵。你的服务器会因为这样的用户开销更大。二、rc4可以缓解beast攻击。因此，禁用rc4使tls 1用户容易受到攻击，通过移动他们aes-cbc（通常的服务器端的beast“修复”是优先考虑高于一切的rc4）。我很确信，在beast上rc4上的缺陷明显大于风险。确实，客户端的缓解（chrome和火狐都提供）beast已不再是个问题。但对于增长rc4的风险：随着时间的推移更多的密码分析将很表面化。

freak攻击

freak是在密码专家小组在inria, microsoft research and imdea所发现的一种中间人攻击。freak就是“factoring rsa-export keys .”。这种攻击可以追溯到90世纪90年代，也就是在美国*禁止出售加密软件到海外的时候，除非输出的密码套件中加密密钥的长度不超过512位。

被证明是一些先进的tls客户端-包括苹果的securetransport和openssl-有一个bug在里面。这个bug造成了它们接受了rsa密钥的输出等级甚至当客户端都不要求rsa的密钥输出等级。这个bug造成的影响还是相当严重的：假如客户端是易受攻击的并且服务器支持输出rsa，它允许第三人通过一个活跃的攻击者来减弱连接的质量进行攻击。

这里是两部分服务器必须接受的“rsa输出等级”攻击。

mitm攻击过成如下：

•     在客户端的hello消息中，它请求一个标准的“rsa”密码套件。
•     mitm攻击者改变这个消息为了得到“rsa的输出”.
•     服务器返回一个512位的rsa输出密钥，并用它的永久密钥签名。
•     由于openssl和securetransport存有bug，客户端就接受了这个弱密钥。
•     攻击者分析rsa模块为了恢复正在通信时rsa的解密密钥。
•     当客户端把加密的“预备主密钥”发送给服务器时，攻击者现在可以解密它从而得到tls的“主密钥”。
•     从现在起，攻击者就可以看到明文了，并且可以注入任何他想的东西。

这个页面上提供密码套件但是支持密码输出等级。确保你的openssl是最近更新过的版本而且你的客户端也要使用最新的软件。

heartbleed(心脏出血)

hearbleed是一个在2014年四月openssl密码库里被发现的安全漏洞，它被广泛用在运输层（tls）协议的实施中。heartbleed可能被使用不管是否使用了一个易受攻击的openssl，比如说在一个服务器或者客户端使用。它是在dtls心跳扩展（rfc6520）由不合适的输入确认（因为没有边界检查）所造成，因此这个漏洞的名字为“心跳”.这个漏洞被划为一个重读的缓冲区，更多超出允许的数据被读出。

哪些版本的openssl被heartbleed影响？

不同版本的情况：

•     openssl 1.0.1 到 1.0.1f (包括) 受攻击。
•     openssl 1.0.1g不受攻击。
•     openssl 1.0.0的分支不受攻击。
•     openssl 0.9.8 的分支不受攻击。

openssl在2011年12月发现这个漏洞而且在2012年3月14日发布openssl1.0.1之前一直没有采取措施。2014年4月7号发布的openssl1.0.1g修复了这个漏洞。

通过更新openssl就可以免受这个漏洞带来的攻击。

ssl 压缩（犯罪攻击）

通常来说，犯罪攻击使用 ssl 压缩来施展它的魔法。ssl 压缩在 nginx1.1.6+/1.0.9+ 中默认是关闭的（如果使用 openssl 1.0.0+).

如果你正在使用 nginx 或者 openssl 其他早期版本，并且你的发行版并没有回迁此选项，那么你需要重新编译不支持 zlib 的 openssl。这将禁止使用deflate压缩方法来使用 openssl。如果你这样做，那么你仍然可以使用常规的html deflate压缩。
sslv2 与 sslv3

ssl v2 并不安全，因此我们需要禁用它。我们也可以禁用 ssl v3，当 tls 1.0 遭受一个降级攻击时，可以允许一个攻击者强迫使用 ssl v3 来连接，因此禁用“向前保密”。

再次编辑此配置文件：
 
ssl_protocols tlsv1 tlsv1.1 tlsv1.2;

贵宾犬攻击和tls-fallback-scsv

sslv3允许利用“贵宾犬 poodle”漏洞，这是禁用它的一个主要原因。google已经提议一种叫tlsfallbackscsv的ssl/tls的拓展，旨在防止强制ssl降级。以下是升级后自动启用的openssl版本：

•     openssl 1.0.1 有 tlsfallbackscsv 在 1.0.1j 及更高的版本.
•     openssl 1.0.0 有 tlsfallbackscsv 在 1.0.0o 及更高的版本.
•     openssl 0.9.8 有 tlsfallbackscsv 在 0.9.8zc 及更高的版本.

更多的信息请参阅nginx文档
密码套件

forward secrecy 确保了在永久密钥被泄漏的事件中，会话密钥的完整性。pfs 实现这些是通过执行推导每个会话的新密钥来完成。

这意味着当私有密钥被泄露不能用来解密ssl流量记录。

密码套件提供 perfect forward secrecy 暂时使用 diffie-hellman 密钥交换的形式。他们的缺点是开销大，这可以通过使用椭圆曲线的变异的改进。

我建议以下两个密码套件，后者来自 mozilla 基金会。

推荐的密码套件:
 

ssl_ciphers 'aes128+eecdh:aes128+edh';

推荐的密码套件向后兼容(ie6 / winxp):
 

ssl_ciphers "ecdhe-rsa-aes256-gcm-sha384:ecdhe-rsa-aes128-gcm-sha256:dhe-rsa-aes256-gcm-sha384:dhe-rsa-aes128-gcm-sha256:ecdhe-rsa-aes256-sha384:ecdhe-rsa-aes128-sha256:ecdhe-rsa-aes256-sha:ecdhe-rsa-aes128-sha:dhe-rsa-aes256-sha256:dhe-rsa-aes128-sha256:dhe-rsa-aes256-sha:dhe-rsa-aes128-sha:ecdhe-rsa-des-cbc3-sha:edh-rsa-des-cbc3-sha:aes256-gcm-sha384:aes128-gcm-sha256:aes256-sha256:aes128-sha256:aes256-sha:aes128-sha:des-cbc3-sha:high:!anull:!enull:!export:!des:!md5:!psk:!rc4";

  如果您的 openssl 是旧版本，不可用密码将被自动丢弃。总是使用完整的密码套件，让openssl选它所支持的。

密码套件的顺序非常重要，因为它决定在优先级算法将被选中。上面的建议重视算法提供完美的向前保密。

老版本的 openssl 可能不会返回算法的完整列表。aes-gcm 和一些 ecdhe 相当近，而不是出现在大多数版本的 ubuntu openssl 附带或 rhel。

优先级逻辑

•     首先选择 ecdhe + aesgcm 密码。这些都是 tls 1.2 密码并没有受到广泛支持。这些密码目前没有已知的攻击目标。
•     pfs 密码套件是首选，ecdhe 第一，然后 dhe。
•     aes 128 更胜 aes 256。有讨论是否 aes256 额外的安全是值得的成本，结果远不明显。目前，aes128 是首选的，因为它提供了良好的安全，似乎真的是快，更耐时机攻击。
•     向后兼容的密码套件，aes 优先 3des。暴力攻击 aes 在 tls1.1 及以上，减轻和 tls1.0 中难以实现。向后不兼容的密码套件，3des 不存在.
•     rc4 被完全移除. 3des 用于向后兼容。 

强制性的丢弃

•     anull 包含未验证 diffie - hellman 密钥交换，受到中间人这个攻击
•     enull 包含未加密密码(明文)
•     export 被美国法律标记为遗留弱密码
•     rc4 包含了密码，使用废弃arcfour算法
•     des 包含了密码，使用弃用数据加密标准
•     sslv2 包含所有密码,在旧版本中定义ssl的标准,现在弃用
•     md5 包含所有的密码，使用过时的消息摘要5作为散列算法

其它的设置

确保你已经添加了以下几行：
 

ssl_prefer_server_ciphers on;
ssl_session_cache shared:ssl:10m;

在sslv3或这是tlsv1握手时选择一个密码，通常是使用客户端的偏好。如果这个指令是启用的，那么服务器反而是使用服务器的偏好。

更多关于ssl preferserver密码的信息

更多关于ssl密码的信息
向前保密（forward secrecy）与diffie hellman ephemeral parameters

向前保密的概念很简单：客户端和服务器协商一个可靠的密钥，并在会话结束后销毁。服务器中的rsa私钥用来签名客户端和服务器之间交换的diffie-hellman密钥。副主密钥从diffie-hellman握手中得到，并用于加密。由于副主密钥在客户端和服务器之间的连接中是明确具体的，并用于有限的时间，因此被叫作ephemeral(短暂的)。

由于有forward secrecy，即使攻击者持有服务器的私钥，也不能够解密过去的会话。私钥仅仅用来签名dh（diffie-hellman）的握手，它并没有泄漏副主密钥。diffie-hellman确保了副主密钥不会离开客户端和服务器，也不会被中间人截获。

1.4.4所有的nginx版本在往diffiel-hellman输入参数时依赖openssl。不幸的时，这就意味着ephemeral diffiel-hellman（dhe）会使用openssl的这一缺陷，包括一个1024位的交换密钥。由于我们正在使用一个2048位的证书，dhe客户端比非ephemeral客户端将使用一个更弱的密钥交换。

我们需要产生一个更强的dhe参数：
cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

然后告诉nginx在dhe密钥交换的时候使用它：
 

ssl_dhparam /etc/ssl/certs/dhparam.pem;

ocsp 适用

在和服务器连接的时候，客户端通过使用证书撤销列表（crl）来验证服务器证书的有效性，或者是使用在线证书状态协议（ocsp）记录。但是crl的问题是：crl的列表项不断增多，而且需要不断地下载。

ocsp是更轻量级的，因为它一次只获取一条记录。但是副作用是，当连接到服务器的时候，ocsp请求必须发送到第三方响应者，这增加了延迟，以及失败的可能。实际上，ocsp响应者由ca操控，由于它常常不可靠，导致浏览器由于收不到适时的响应而失败。这减少了安全性，因为它允许攻击者对ocsp响应者进行dos攻击来取消验证。

解决方案是在tls握手期间，允许服务器发送缓存的ocsp记录，这样来绕过ocsp响应者。这个技术节省了在客户端和ocsp响应者之间的一个来回，称为ocsp闭合（ocsp stapling）。

服务器只在客户端请求的时候，发送一个缓存的ocsp响应，通过对client hello的status_request tls拓展来声明支持。

大多数服务器都会缓存ocsp响应到48小时。在常规间隔，服务器会连接到ca的ocsp响应者来获取最新的ocsp记录。ocsp响应者的位置是从签名证书的authority information access 字段来获取。

http strict transport security

如果可能，你应该开启 http strict transport security (hsts) ，它指示浏览器只通过https来访问你的站点。

http public key pinning extension

你同样应该开启 http public key pinning extension。

public key pinning 意味着证书链必须包含处于白名单之中的公钥。它确保只在白名单中的ca可以对*.example.com进行签名，而不是浏览器中保存的任何一个ca。

我已经写了关于它的一篇文章，包含背景理论和配置实例，针对 apache， lighttpd 以及 nginx：https://raymii.org/s/articles/httppublickeypinningextension_hpkp.html
配置示例
 

server {
 
  listen [::]:443 default_server;
 
  ssl on;
  ssl_certificate_key /etc/ssl/cert/raymii_org.pem;
  ssl_certificate /etc/ssl/cert/ca-bundle.pem;
 
  ssl_ciphers 'aes128+eecdh:aes128+edh:!anull';
 
  ssl_protocols tlsv1 tlsv1.1 tlsv1.2;
  ssl_session_cache shared:ssl:10m;
 
  ssl_stapling on;
  ssl_stapling_verify on;
  resolver 8.8.4.4 8.8.8.8 valid=300s;
  resolver_timeout 10s;
 
  ssl_prefer_server_ciphers on;
  ssl_dhparam /etc/ssl/certs/dhparam.pem;
 
  add_header strict-transport-security max-age=63072000;
  add_header x-frame-options deny;
  add_header x-content-type-options nosniff;
 
  root /var/www/;
  index index.html index.htm;
  server_name raymii.org;
 
}

结论

如果你应用了上面的配置文件，你需要重启nginx:

# check the config first:
/etc/init.d/nginx configtest
# then restart:
/etc/init.d/nginx restart

现在使用ssl 实验室测试（ssl labs tes）看看你是否得到一个漂亮的a。同时，当然，拥有一个安全的，牢靠的，作为未来样例的ssl配置。