本文介绍了在Debian和Ubuntu系统平台上实施完美前向保密(Perfect Forward Secrecy)以及NGINX网站服务器的过程。如果是其他GNU/Linux系统，整个过程稍有变动。

　　简而言之，完美前向保密可以确保“即便一个信息受危及，也不会拖累其他信息受危及；并确保没有一个秘密值会导致多个消息受危及。”想了解更多信息，请参阅维基百科上的相关解释：http：//en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy。

　　当openSSL中的Heartbleed安全漏洞于2014年年初公之于众时，这个事实显得越来越清楚：对于在很大程度上采用SSL/TLS的任何系统而言，完美前向保密必不可少。

　　万一你希望将自己的结果与我的结果进行比较，可以在https：//www.ssllabs.com/ssltest/analyze.html？d=indietorrent.org处测试我的参照实施方法，SSL证书链和发送的NGINX报头可以在https：//indietorrent.org处查看。

　　闲话少说，不妨配置NGINX来实施完美前向保密。

　　先不妨进入到NGINX的配置目录：

　　cd /etc/nginx/

　　我们需要生成安全性足够强的Diffie-Hellman参数。一些人认为，4096比特过长了，会给系统的处理器带来不必要的负担；但是就现在的计算能力而言，这似乎值得一试。想了解更多信息，请参阅下面的“参考资料”部分。

　　openssl dhparam -out dh4096.pem 4096

　　要是有这个配置文件很方便，该文件是专门针对手头的任务，在include文件中被划分开来；这样一来，更容易跨数量众多的系统来实施完美前向保密。

　　vi /etc/nginx/perfect-forward-secrecy.conf

　　将下列内容粘贴到上述文件中：

　　ssl_protocols TLSv1 TLSv1.1 TLSv1.2；

　　ssl_prefer_server_ciphers on；

　　ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384

　　EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4

　　EECDH EDH+aRSA RC4 ！aNULL ！eNULL ！LOW ！3DES ！MD5 ！EXP ！PSK ！SRP ！DSS ！MEDIUM"；

　　ssl_dhparam dh4096.pem；

　　修改NGINX配置，以便加入上述文件，为此只要在http {}代码段的末尾，将下面这一行插入到NGINX的主配置文件(默认情况下主配置文件是/etc/nginx/nginx.conf)：

　　#See：https：//community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

　　#This MUST come AFTER the lines that includes …/sites-enabled/*， otherwise SSLv3 support may be re-enabled accidentally.

　　include perfect-forward-secrecy.conf；

　　重启NGINX，让变更内容生效：

　　service nginx restart

　　要是https：//www.ssllabs.com/ssltest/analyze.html处的测试显示红色的Session resumption (caching) No (IDs assigned but not accepted)，并且服务器实施了服务器名字指示(SNI)，那就添加下列内容到顶层的http {}代码段(即添加到nginx.conf，就在我们之前所添加内容的下面)：

　　# See： http：//forum.nginx.org/read.php？2，152294，152401#msg-152401

　　ssl_session_cache shared：SSL：10m；

　　同样，重启NGINX，让变更内容生效：

　　service nginx restart

　　上述测试应该不再报告这个问题了(尽管这个问题并不降低总体测试分数)。

　　更深入一步：实施持续时间长的HTTP严格传输安全(HSTS)协议

　　这部分很容易实现，完全值得一试，前提是：

　　1.针对该报头所设置的任何主机，你想要强行要求使用SSL访问所有资源(也就是相关网站上的每个网页)。

　　2.你可以忍受不能够接受和忽视针对该报头所设置的任何主机而请求的任何资源的SSL提醒，比如“Domain Name Mismatch”等。HSTS的性质恰恰在于，与SSL证书有关的警告和错误条件无法被覆盖。

　　我上网搜索了关于设置该报头会不会可能给不支持报头的浏览器带来不必要的影响方面的信息，结果发现信息寥。但我能够通过在浏览器(比如IE 6)中测试这个实施方法来消除我担心的问题，没有实施HSTS的浏览器完全忽视报头。太棒了！

　　只要将下面几行添加到/etc/nginx/perfect-forward-secrecy.conf的末尾，保存变更内容：

　　add_header Strict-Transport-Security "max-age=31536000； includeSubDomains"；

　　# This will prevent certain click-jacking attacks， but will prevent

　　# other sites from framing your site， so delete or modify as necessary！

　　add_header X-Frame-Options SAMEORIGIN；

　　重新加载(而不是重启)将足以迫使NGINX采用这些特别的变更：

　　service nginx reload

　　可以证实 HSTS按预期的方式运行，只要在https：//www.ssllabs.com/ssltest/analyze.html处证实这个实施方法。如果HSTS已正确实施，你应该会在分数正下方看到一个绿色框，显示“This server supports HTTP Strict Transport Security with long duration. Grade set to A+.”意为“该服务器支持持续时间长的HTTP严格传输安全协议。分数被定为A+。”

　　祝贺你！

　　现在，你拥有了互联网上最安全的SSL/TLS实施方法之一。