本文向你们展示如何在nginx的web服务器上设置更强的SSL。我们是通过使SSL无效来减弱CRIME攻击的这种方法实现。不使用在协议中易受攻击的SSLv3以及以下版本并且我们会设置一个更强的密码套件为了在可能的情况下能够实现Forward Secrecy，同时我们还启用HSTS和HPKP。这样我们就有了一个更强、不过时的SSL配置并且我们在Qually Labs SSL 测试中得到了A等级。
我们在nginx的设置文档中如下编辑
对于整个说明文档，你需要编辑服务器配置的服务器那块和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攻击过成如下：
这个页面上提供密码套件但是支持密码输出等级。确保你的OpenSSl是最近更新过的版本而且你的客户端也要使用最新的软件。
Heartbleed(心脏出血)
Hearbleed是一个在2014年四月OpenSSL密码库里被发现的安全漏洞，它被广泛用在运输层（TLS）协议的实施中。Heartbleed可能被使用不管是否使用了一个易受攻击的OpenSSL，比如说在一个服务器或者客户端使用。它是在DTLS心跳扩展（RFC6520）由不合适的输入确认（因为没有边界检查）所造成，因此这个漏洞的名字为“心跳”.这个漏洞被划为一个重读的缓冲区，更多超出允许的数据被读出。
哪些版本的OpenSSL被Heartbleed影响？
不同版本的情况：
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版本：
更多的信息请参阅NGINX文档
密码套件
Forward Secrecy 确保了在永久密钥被泄漏的事件中，会话密钥的完整性。PFS 实现这些是通过执行推导每个会话的新密钥来完成。
这意味着当私有密钥被泄露不能用来解密SSL流量记录。
密码套件提供 Perfect Forward Secrecy 暂时使用 Diffie-Hellman 密钥交换的形式。他们的缺点是开销大，这可以通过使用椭圆曲线的变异的改进。
我建议以下两个密码套件，后者来自 Mozilla 基金会。
推荐的密码套件:
推荐的密码套件向后兼容(IE6 / WinXP):
如果您的 OpenSSL 是旧版本，不可用密码将被自动丢弃。总是使用完整的密码套件，让OpenSSL选它所支持的。
密码套件的顺序非常重要，因为它决定在优先级算法将被选中。上面的建议重视算法提供完美的向前保密。
老版本的 OpenSSL 可能不会返回算法的完整列表。AES-GCM 和一些 ECDHE 相当近，而不是出现在大多数版本的 Ubuntu OpenSSL 附带或 RHEL。
优先级逻辑
强制性的丢弃
其它的设置
确保你已经添加了以下几行：
在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密钥交换的时候使用它：
在和服务器连接的时候，客户端通过使用证书撤销列表（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
配置示例
如果你应用了上面的配置文件，你需要重启nginx:
现在使用SSL 实验室测试（SSL Labs tes）看看你是否得到一个漂亮的A。同时，当然，拥有一个安全的，牢靠的，作为未来样例的SSL配置。
京公网安备 11010802040832号 | 京ICP备19059560号-6 