概要
OpenSSL 是一个强大的安全套接字层密码库，囊括主要的密码算法、常用的密钥和证书封装管理功能及SSL协议，并提供丰富的应用程序供测试或其它目的使用。
本文主要阐述如何在nginx的web服务器上设置更强的SSL。不使用在SSL/TLS协议中易受攻击的SSLv3以及以下版本并且设置一个更强的密码套件，同时启用HSTS和HPKP，为在可能的情况下能够实现Forward Secrecy。
SSL安全测试验证网站：https://www.ssllabs.com/ssltest/
配置文件及对应安全选项说明
1）配置文件位置，默认ssl端口采用443，实际中可按需修改：
Ubuntu/Debian：/etc/nginx/sited-enabled/yoursite.com
RHEL/CentOS：/etc/nginx/conf.d/nginx.conf
注：修改配置文件之前请备份文件或相关选项，生产环境特别注意。
2）风险：
（1）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的风险：随着时间的推移更多的密码分析将很表面化。
（2）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输出等级”攻击。
（3）MITM攻击：
过程如下：
在客户端的Hello消息中，它请求一个标准的“RSA”密码套件。
MITM攻击者改变这个消息为了得到“RSA的输出”.
服务器返回一个512位的RSA输出密钥，并用它的永久密钥签名。
由于OpenSSL和SecureTransport存有bug，客户端就接受了这个弱密钥。
攻击者分析RSA模块为了恢复正在通信时RSA的解密密钥。
当客户端把加密的“预备主密钥”发送给服务器时，攻击者现在可以解密它从而得到TLS的“主密钥”。
从现在起，攻击者就可以看到明文了，并且可以注入任何他想的东西。
这个页面上提供密码套件但是支持密码输出等级。确保你的OpenSSl是最近更新过的版本而且你的客户端也要使用最新的软件。
（4）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就可以免受这个漏洞带来的攻击。
（5）SSL 压缩（犯罪攻击）
通常来说，犯罪攻击使用 SSL 压缩来施展它的魔法。SSL 压缩在 nginx1.1.6+/1.0.9+ 中默认是关闭的（如果使用 openssl 1.0.0+).
如果你正在使用 nginx 或者 OpenSSL 其他早期版本，并且你的发行版并没有回迁此选项，那么你需要重新编译不支持 ZLIB 的 OpenSSL。这将禁止使用DEFLATE压缩方法来使用 OpenSSL。如果你这样做，那么你仍然可以使用常规的HTML DEFLATE压缩。
（6）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 及更高的版本.
（7）密码套件
Forward Secrecy 确保了在永久密钥被泄漏的事件中，会话密钥的完整性。PFS 实现这些是通过执行推导每个会话的新密钥来完成。
这意味着当私有密钥被泄露不能用来解密SSL流量记录。
密码套件提供 Perfect Forward Secrecy 暂时使用 Diffie-Hellman 密钥交换的形式。他们的缺点是开销大，这可以通过使用椭圆曲线的变异的改进。
eg1：
ssl_ciphers 'AES128+EECDH:AES128+EDH';
eg2：来自 Mozilla 基金会，后兼容(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 是旧版本，不可用密码将被自动丢弃。nginx会总是使用完整的密码套件，让OpenSSL选它所支持的。密码套件的顺序也非常重要，它决定了通信时采用的优先级算法。上面的建议的2个密码套件示例，重视了算法提供完美的向前保密。老版本的 OpenSSL 可能不会返回算法的完整列表。AES-GCM 和一些 ECDHE 相当近，而不是出现在大多数版本的 Ubuntu OpenSSL 附带或 RHEL。
新版本中，可通过命令： nmap --script ssl-cert,ssl-enum-ciphers -p 443 host_ip，到如下部分信息：
|TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_ECDHE_RSA_WITH_RC4_128_SHA - strong
| TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA - broken
| TLS_ECDH_anon_WITH_AES_128_CBC_SHA - broken
| TLS_ECDH_anon_WITH_AES_256_CBC_SHA - broken
| TLS_ECDH_anon_WITH_RC4_128_SHA - broken
| TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 - weak
| TLS_RSA_EXPORT_WITH_RC4_40_MD5 - weak
| TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong
| TLS_RSA_WITH_AES_128_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA - strong
| TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
| TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
现场：A，B，C，C级属于不满足要求的
MD5: d272 52c0 b2ee 64ec ed34 07f1 643b 87a9
|_SHA-1: a098 6a65 4df2 cbb6 b859 e40a 953c bb91 c4f8 f639
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
| TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
上面的输出中，weak、strong字段，weak都是40位加密的，strong应该都在128位以上的。Nginx 的 SSL 时不指定 ssl_ciphers时，默认允许使用的加密算法和协议将会包括一些已经证实不够安全的算法及协议，如对称加密密钥不足 128-bit 的算法；了保证 SSL 连接足够安全，将128位以下弱加密算法禁用，在配置时应该明确指定算法：
ssl_ciphers HIGH:!ADH:!MD5;
另openssl已报出SSL/TLS协议信息泄露漏洞(CVE-2016-2183)，描述如下：
TLS, SSH, IPSec协商及其他产品中使用的DES及Triple DES密码存在大约四十亿块的生日界，这可使远程攻击者通过Sweet32攻击，官方建议https://www.openssl.org/news/secadv/20160922.txt ，将OpenSSL 1.0.2 users should upgrade to 1.0.2i。另外，为了缓解基于DES的SWEET32攻击，在OpenSSL 1.0.1和OpenSSL 1.0.2版本中，DES密码套件已经从高密码串组移动到中密码串组。
（8）优先级逻辑
首先选择 ECDHE + AESGCM 密码。这些都是 TLS 1.2 密码并没有受到广泛支持。这些密码目前没有已知的攻击目标。
PFS 密码套件是首选，ECDHE 第一，然后 DHE。
AES 128 更胜 AES 256。有讨论是否 AES256 额外的安全是值得的成本，结果远不明显。目前，AES128 是首选的，因为它提供了良好的安全，似乎真的是快，更耐时机攻击。
向后兼容的密码套件，AES 优先 3DES。暴力攻击 AES 在 TLS1.1 及以上，减轻和 TLS1.0 中难以实现。向后不兼容的密码套件，3DES 不存在.
RC4 被完全移除. 3DES 用于向后兼容。
（9）强制性的丢弃
aNULL 包含未验证 diffie - hellman 密钥交换，受到中间人这个攻击
eNULL 包含未加密密码(明文)
EXPORT 被美国法律标记为遗留弱密码
RC4 包含了密码，使用废弃ARCFOUR算法
DES 包含了密码，使用弃用数据加密标准
SSLv2 包含所有密码,在旧版本中定义SSL的标准,现在弃用
MD5 包含所有的密码，使用过时的消息摘要5作为散列算法
3）openssl支持的加密算法
（1）对称加密算法
OpenSSL一共提供了8种对称加密算法，其中7种是分组加密算法，仅有的一种流加密算法是RC4。这7种分组加密算法分别是AES、DES、Blowfish、CAST、IDEA、RC2、RC5，都支持电子密码本模式（ECB）、加密分组链接模式（CBC）、加密反馈模式（CFB）和输出反馈模式（OFB）四种常用的分组密码加密模式。其中，AES使用的加密反馈模式（CFB）和输出反馈模式（OFB）分组长度是128位，其它算法使用的则是64位。事实上，DES算法里面不仅仅是常用的DES算法，还支持三个密钥和两个密钥3DES算法。
（2）非对称加密算法
OpenSSL一共实现了4种非对称加密算法，包括DH算法、RSA算法、DSA算法和椭圆曲线算法（EC）。
DH算法一般用户密钥交换。
RSA算法既可以用于密钥交换，也可以用于数字签名。
DSA算法则一般只用于数字签名。
（3）信息摘要算法
OpenSSL实现了5种信息摘要算法，分别是MD2、MD5、MDC2、SHA（SHA1）和RIPEMD。SHA算法事实上包括了SHA和SHA1两种信息摘要算法，此外，OpenSSL还实现了DSS标准中规定的两种信息摘要算法DSS和DSS1。
4）Nginx中禁用DES算法：
（1）查看当前openssl支持的算法：openssl ciphers -V
其中，Kx表密钥交换算法 ：用来协商回话密钥；Au表验证算法 ：用来验证服务端身份；Enc对称加密算法：加密消息；Mac摘要算法：防消息篡改。nginx 默认配置是 HIGH:!aNULL:!MD5
（2）禁用DES加密：
执行nginx -t确认当前nginx配置文件位置，进行修改，nginx配置文件中cipher选项算法列表包含一个或多个:用冒号隔开。感叹号!表示禁止此算法，这样在浏览器使用不安全的算法时，会自动禁止连接。
验证：nmap -Pn --script ssl-cert,ssl-enum-ciphers -p 443 host_ip
如上所述，其中TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) 和TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) 和TLS_RSA_WITH_3DES_EDE_CBC_SHA(rsa 2048)
这是因为另一台服务器，我尚未配置，禁用DES加密算法后，再次测试，效果如下
5）Nginx其他安全配置
确保Nginx.conf里添加以下选项，在SSLv3或这是TLSv1握手时选择一个密码：
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
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。
6）向前保密（Forward Secrecy）
向前保密的概念很简单：客户端和服务器协商一个可靠的密钥，并在会话结束后销毁。服务器中的RSA私钥用来签名客户端和服务器之间交换的Diffie-Hellman密钥。副主密钥从Diffie-Hellman握手中得到，并用于加密。由于副主密钥在客户端和服务器之间的连接中是明确具体的，并用于有限的时间，因此被叫作Ephemeral(短暂的)。
由于有Forward Secrecy，即使攻击者持有服务器的私钥，也不能够解密过去的会话。私钥仅仅用来签名DH（Diffie-Hellman）的握手，它并没有泄漏副主密钥。Diffie-Hellman确保了副主密钥不会离开客户端和服务器，也不会被中间人截获。
所有的nginx版本在往Diffiel-Hellman输入参数时依赖OpenSSL。不幸的时，这就意味着Diffiel-Hellman Ephemeral （DHE）会使用OpenSSL的这一缺陷，包括一个1024位的交换密钥。由于我们正在使用一个2048位的证书，而DHE客户端比非ephemeral客户端就会使用一个更弱的密钥交换。因此，我们需要产生一个更强的DHE参数，执行：
cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096
vi /etc/nginx/nginx.conf,写入：ssl_dhparam /etc/ssl/certs/dhparam.pem;这样，nginx在DHE密钥交换的时就会用dhparam.pem；
7）OCSP 适用
OCSP 称 Online Certificate Status Protocol，即在线证书状态协议。
在和服务器连接的时候，客户端通过使用证书撤销列表（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 字段来获取。
命令检测：
openssl s_client -connect ffis.me:443 -servername ffis.me -status -tlsextdebug < /dev/null 2>&1 | grep -i “OCSP response”
# 开启 OCSP Stapling，开启后服务器在TLS握手时发送事先缓存的OCSP响应，用户只需验证该响应的有效性而不用再向数字证书认证机构（CA）发送请求
ssl_stapling on;
# 启用或禁用服务器对OCSP响应的验证
ssl_stapling_verify on;
# 证书的签发机构的ca证书，我的Let's Encrypt是acme.sh自动获取的证书，ca证书目录为：/root/.acme.sh/ffis.me/ca.cer
ssl_trusted_certificate /usr/local/nginx/conf/ssl/ffis.me_ca.cer;
# 添加resolver解析OSCP响应服务器的主机名，valid表示缓存。这里添加是为了解决DNS污染问题。
resolver 8.8.8.8 8.8.4.4 223.5.5.5 valid=60s;
# 网络超时时间
resolver_timeout 2s;
问题遗留：实现了OCSP查询在服务器端进行，避免了浏览器去进行OCSP验证从而影响访问速度；
但是OCSP响应的缓存并不是预加载的，而是异步加载的；在Nginx启动后，只有当有客户端访问的时候，Nginx才开始去请求OCSP响应并缓存到本地，并且当OCSP响应缓存过期的时候并不会去主动更新，而是等待客户端访问异步触发的更新；
这样就会导致总会有几次访问并没有走OCSP响应缓存从而导致还是会有访问速度缓慢的情况发生。
【OCSP漏洞】：
OpenSSL OCSP 状态请求扩展存在严重漏洞，该漏洞令恶意客户端能耗尽服务器内存。利用该漏洞，能使默认配置的服务器在每次协议重商时分配一段 OCSP ids 内存， 不断重复协商可令服务器内存无限消耗，即使服务器并未配置 OCSP。理论上，一个 OCSP id 最多 65,535 字节，攻击者可以不断重商令服务器每次内存消耗近 64K。但从实现来说，在 OpenSSL 1.0.2 版本中对 ClientHello 长度做了 16,384 字节的限制，因此每次重商只能令服务器内存消耗约 16K。但在最新的 1.1.0 版本中，对 ClientHello 长度的限制增加到 131,396 字节，那么对使用 1.1.0 版本的服务器，每次重商会令内存消耗近 64K。
影响版本：
OpenSSL 0.9.8h through 0.9.8v
OpenSSL 1.0.1 through 1.0.1t
OpenSSL 1.0.2 through 1.0.1h
OpenSSL 1.1.0
不受影响版本：
OpenSSL 1.0.1u
OpenSSL 1.0.2i
OpenSSL 1.1.0a
处理建议：升级到最新版本可避免被攻击。 不需要注销私钥或证书，攻击者不能窃取到私钥。 https://www.openssl.org/source/
5）Nginx安全配置示例
server {
listen [::]:443 default_server;
ssl on;
ssl_certificate_key /etc/ssl/cert/blue.pem;
ssl_certificate /etc/ssl/cert/ca-blue.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;
}