本文向你們展示如何在nginx的web服務(wù)器上設(shè)置更強(qiáng)的SSL。我們是通過使SSL無效來減弱CRIME攻擊的這種方法實(shí)現(xiàn)。不使用在協(xié)議中易受攻擊的SSLv3以及以下版本并且我們會設(shè)置一個(gè)更強(qiáng)的密碼套件為了在可能的情況下能夠?qū)崿F(xiàn)Forward Secrecy，同時(shí)我們還啟用HSTS和HPKP。這樣我們就有了一個(gè)更強(qiáng)、不過時(shí)的SSL配置并且我們在Qually Labs SSL 測試中得到了A等級。

我們在nginx的設(shè)置文檔中如下編輯

對于整個(gè)說明文檔，你需要編輯服務(wù)器配置的服務(wù)器那塊和443端口（SSL配置）。在說明文檔的最后，你會發(fā)現(xiàn)實(shí)現(xiàn)了樣例的配置。

確保在編輯之前做了備份！

BEAST攻擊和RC4算法

簡言之，就是通過篡改加密算法CBC密碼塊的加密模式，部分加密流量可以被偷偷地解密。更多的信息請參照以上鏈接。

新版本的瀏覽器客戶端可以緩解BEASE攻擊。建議禁用所有的TLS 1.0密碼并且只是用RC4。然而，[RC4有一個(gè)不斷增加的列表來防止攻擊]，(http://www.isg.rhul.ac.uk/tls/)其中的很多都將理論和現(xiàn)實(shí)交叉在一起。而且，這就是為什么NSA已經(jīng)破解了RC4，他們所謂的“重大的突破”。

禁用RC4有幾個(gè)結(jié)果。一、使用差勁兒瀏覽器的用戶將使用3DES來代替。3-DES比RC4更安全。但是就意味著更加昂貴。你的服務(wù)器會因?yàn)檫@樣的用戶開銷更大。二、RC4可以緩解BEAST攻擊。因此，禁用RC4使TLS 1用戶容易受到攻擊，通過移動他們AES-CBC（通常的服務(wù)器端的BEAST“修復(fù)”是優(yōu)先考慮高于一切的RC4）。我很確信，在BEAST上RC4上的缺陷明顯大于風(fēng)險(xiǎn)。確實(shí)，客戶端的緩解（chrome和火狐都提供）BEAST已不再是個(gè)問題。但對于增長RC4的風(fēng)險(xiǎn)：隨著時(shí)間的推移更多的密碼分析將很表面化。

FREAK攻擊

FREAK是在密碼專家小組在INRIA, Microsoft Research and IMDEA所發(fā)現(xiàn)的一種中間人攻擊。FREAK就是“Factoring RSA-EXPORT Keys .”。這種攻擊可以追溯到90世紀(jì)90年代，也就是在美國政府禁止出售加密軟件到海外的時(shí)候，除非輸出的密碼套件中加密密鑰的長度不超過512位。

被證明是一些先進(jìn)的TLS客戶端-包括蘋果的SecureTransport和OpenSSL-有一個(gè)Bug在里面。這個(gè)Bug造成了它們接受了RSA密鑰的輸出等級甚至當(dāng)客戶端都不要求RSA的密鑰輸出等級。這個(gè)Bug造成的影響還是相當(dāng)嚴(yán)重的：假如客戶端是易受攻擊的并且服務(wù)器支持輸出RSA，它允許第三人通過一個(gè)活躍的攻擊者來減弱連接的質(zhì)量進(jìn)行攻擊。

這里是兩部分服務(wù)器必須接受的“RSA輸出等級”攻擊。

MITM攻擊過成如下：

•     在客戶端的Hello消息中，它請求一個(gè)標(biāo)準(zhǔn)的“RSA”密碼套件。
•     MITM攻擊者改變這個(gè)消息為了得到“RSA的輸出”.
•     服務(wù)器返回一個(gè)512位的RSA輸出密鑰，并用它的永久密鑰簽名。
•     由于OpenSSL和SecureTransport存有bug，客戶端就接受了這個(gè)弱密鑰。
•     攻擊者分析RSA模塊為了恢復(fù)正在通信時(shí)RSA的解密密鑰。
•     當(dāng)客戶端把加密的“預(yù)備主密鑰”發(fā)送給服務(wù)器時(shí)，攻擊者現(xiàn)在可以解密它從而得到TLS的“主密鑰”。
•     從現(xiàn)在起，攻擊者就可以看到明文了，并且可以注入任何他想的東西。

這個(gè)頁面上提供密碼套件但是支持密碼輸出等級。確保你的OpenSSl是最近更新過的版本而且你的客戶端也要使用最新的軟件。

Heartbleed(心臟出血)

Hearbleed是一個(gè)在2014年四月OpenSSL密碼庫里被發(fā)現(xiàn)的安全漏洞，它被廣泛用在運(yùn)輸層（TLS）協(xié)議的實(shí)施中。Heartbleed可能被使用不管是否使用了一個(gè)易受攻擊的OpenSSL，比如說在一個(gè)服務(wù)器或者客戶端使用。它是在DTLS心跳擴(kuò)展（RFC6520）由不合適的輸入確認(rèn)（因?yàn)闆]有邊界檢查）所造成，因此這個(gè)漏洞的名字為“心跳”.這個(gè)漏洞被劃為一個(gè)重讀的緩沖區(qū)，更多超出允許的數(shù)據(jù)被讀出。

哪些版本的OpenSSL被Heartbleed影響？

不同版本的情況：

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

OpenSSL在2011年12月發(fā)現(xiàn)這個(gè)漏洞而且在2012年3月14日發(fā)布OpenSSL1.0.1之前一直沒有采取措施。2014年4月7號發(fā)布的OpenSSL1.0.1g修復(fù)了這個(gè)漏洞。

通過更新OpenSSL就可以免受這個(gè)漏洞帶來的攻擊。

SSL 壓縮（犯罪攻擊）

通常來說，犯罪攻擊使用 SSL 壓縮來施展它的魔法。SSL 壓縮在 nginx1.1.6+/1.0.9+ 中默認(rèn)是關(guān)閉的（如果使用 openssl 1.0.0+).

如果你正在使用 nginx 或者 OpenSSL 其他早期版本，并且你的發(fā)行版并沒有回遷此選項(xiàng)，那么你需要重新編譯不支持 ZLIB 的 OpenSSL。這將禁止使用DEFLATE壓縮方法來使用 OpenSSL。如果你這樣做，那么你仍然可以使用常規(guī)的HTML DEFLATE壓縮。
SSLV2 與 SSLv3

SSL v2 并不安全，因此我們需要禁用它。我們也可以禁用 SSL v3，當(dāng) TLS 1.0 遭受一個(gè)降級攻擊時(shí)，可以允許一個(gè)攻擊者強(qiáng)迫使用 SSL v3 來連接，因此禁用“向前保密”。

再次編輯此配置文件：
 
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

貴賓犬攻擊和TLS-FALLBACK-SCSV

SSLv3允許利用“貴賓犬 POODLE”漏洞，這是禁用它的一個(gè)主要原因。Google已經(jīng)提議一種叫TLSFALLBACKSCSV的SSL/TLS的拓展，旨在防止強(qiáng)制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 實(shí)現(xiàn)這些是通過執(zhí)行推導(dǎo)每個(gè)會話的新密鑰來完成。

這意味著當(dāng)私有密鑰被泄露不能用來解密SSL流量記錄。

密碼套件提供 Perfect Forward Secrecy 暫時(shí)使用 Diffie-Hellman 密鑰交換的形式。他們的缺點(diǎn)是開銷大，這可以通過使用橢圓曲線的變異的改進(jìn)。

我建議以下兩個(gè)密碼套件，后者來自 Mozilla 基金會。

推薦的密碼套件:
 

推薦的密碼套件向后兼容(IE6 / WinXP):
 

  如果您的 OpenSSL 是舊版本，不可用密碼將被自動丟棄?？偸鞘褂猛暾拿艽a套件，讓OpenSSL選它所支持的。

密碼套件的順序非常重要，因?yàn)樗鼪Q定在優(yōu)先級算法將被選中。上面的建議重視算法提供完美的向前保密。

老版本的 OpenSSL 可能不會返回算法的完整列表。AES-GCM 和一些 ECDHE 相當(dāng)近，而不是出現(xiàn)在大多數(shù)版本的 Ubuntu OpenSSL 附帶或 RHEL。

優(yōu)先級邏輯

•     首先選擇 ECDHE + AESGCM 密碼。這些都是 TLS 1.2 密碼并沒有受到廣泛支持。這些密碼目前沒有已知的攻擊目標(biāo)。
•     PFS 密碼套件是首選，ECDHE 第一，然后 DHE。
•     AES 128 更勝 AES 256。有討論是否 AES256 額外的安全是值得的成本，結(jié)果遠(yuǎn)不明顯。目前，AES128 是首選的，因?yàn)樗峁┝肆己玫陌踩?，似乎真的是快，更耐時(shí)機(jī)攻擊。
•     向后兼容的密碼套件，AES 優(yōu)先 3DES。暴力攻擊 AES 在 TLS1.1 及以上，減輕和 TLS1.0 中難以實(shí)現(xiàn)。向后不兼容的密碼套件，3DES 不存在.
•     RC4 被完全移除. 3DES 用于向后兼容。 

強(qiáng)制性的丟棄

•     aNULL 包含未驗(yàn)證 diffie - hellman 密鑰交換，受到中間人這個(gè)攻擊
•     eNULL 包含未加密密碼(明文)
•     EXPORT 被美國法律標(biāo)記為遺留弱密碼
•     RC4 包含了密碼，使用廢棄ARCFOUR算法
•     DES 包含了密碼，使用棄用數(shù)據(jù)加密標(biāo)準(zhǔn)
•     SSLv2 包含所有密碼,在舊版本中定義SSL的標(biāo)準(zhǔn),現(xiàn)在棄用
•     MD5 包含所有的密碼，使用過時(shí)的消息摘要5作為散列算法

其它的設(shè)置

確保你已經(jīng)添加了以下幾行：
 

在SSLv3或這是TLSv1握手時(shí)選擇一個(gè)密碼，通常是使用客戶端的偏好。如果這個(gè)指令是啟用的，那么服務(wù)器反而是使用服務(wù)器的偏好。

更多關(guān)于SSL preferserver密碼的信息

更多關(guān)于SSL密碼的信息
向前保密（Forward Secrecy）與Diffie Hellman Ephemeral Parameters

向前保密的概念很簡單：客戶端和服務(wù)器協(xié)商一個(gè)可靠的密鑰，并在會話結(jié)束后銷毀。服務(wù)器中的RSA私鑰用來簽名客戶端和服務(wù)器之間交換的Diffie-Hellman密鑰。副主密鑰從Diffie-Hellman握手中得到，并用于加密。由于副主密鑰在客戶端和服務(wù)器之間的連接中是明確具體的，并用于有限的時(shí)間，因此被叫作Ephemeral(短暫的)。

由于有Forward Secrecy，即使攻擊者持有服務(wù)器的私鑰，也不能夠解密過去的會話。私鑰僅僅用來簽名DH（Diffie-Hellman）的握手，它并沒有泄漏副主密鑰。Diffie-Hellman確保了副主密鑰不會離開客戶端和服務(wù)器，也不會被中間人截獲。

1.4.4所有的nginx版本在往Diffiel-Hellman輸入?yún)?shù)時(shí)依賴OpenSSL。不幸的時(shí)，這就意味著Ephemeral Diffiel-Hellman（DHE）會使用OpenSSL的這一缺陷，包括一個(gè)1024位的交換密鑰。由于我們正在使用一個(gè)2048位的證書，DHE客戶端比非ephemeral客戶端將使用一個(gè)更弱的密鑰交換。

我們需要產(chǎn)生一個(gè)更強(qiáng)的DHE參數(shù)：
cd /etc/ssl/certs
openssl dhparam -out dhparam.pem 4096

然后告訴nginx在DHE密鑰交換的時(shí)候使用它：
 

在和服務(wù)器連接的時(shí)候，客戶端通過使用證書撤銷列表（CRL）來驗(yàn)證服務(wù)器證書的有效性，或者是使用在線證書狀態(tài)協(xié)議（OCSP）記錄。但是CRL的問題是：CRL的列表項(xiàng)不斷增多，而且需要不斷地下載。

OCSP是更輕量級的，因?yàn)樗淮沃猾@取一條記錄。但是副作用是，當(dāng)連接到服務(wù)器的時(shí)候，OCSP請求必須發(fā)送到第三方響應(yīng)者，這增加了延遲，以及失敗的可能。實(shí)際上，OCSP響應(yīng)者由CA操控，由于它常常不可靠，導(dǎo)致瀏覽器由于收不到適時(shí)的響應(yīng)而失敗。這減少了安全性，因?yàn)樗试S攻擊者對OCSP響應(yīng)者進(jìn)行DoS攻擊來取消驗(yàn)證。

解決方案是在TLS握手期間，允許服務(wù)器發(fā)送緩存的OCSP記錄，這樣來繞過OCSP響應(yīng)者。這個(gè)技術(shù)節(jié)省了在客戶端和OCSP響應(yīng)者之間的一個(gè)來回，稱為OCSP閉合（OCSP Stapling）。

服務(wù)器只在客戶端請求的時(shí)候，發(fā)送一個(gè)緩存的OCSP響應(yīng)，通過對CLIENT HELLO的status_request TLS拓展來聲明支持。

大多數(shù)服務(wù)器都會緩存OCSP響應(yīng)到48小時(shí)。在常規(guī)間隔，服務(wù)器會連接到CA的OCSP響應(yīng)者來獲取最新的OCSP記錄。OCSP響應(yīng)者的位置是從簽名證書的Authority Information Access 字段來獲取。

HTTP Strict Transport Security

如果可能，你應(yīng)該開啟 HTTP Strict Transport Security (HSTS) ，它指示瀏覽器只通過HTTPS來訪問你的站點(diǎn)。

HTTP Public Key Pinning Extension

你同樣應(yīng)該開啟 HTTP Public Key Pinning Extension。

Public Key Pinning 意味著證書鏈必須包含處于白名單之中的公鑰。它確保只在白名單中的CA可以對*.example.com進(jìn)行簽名，而不是瀏覽器中保存的任何一個(gè)CA。

我已經(jīng)寫了關(guān)于它的一篇文章，包含背景理論和配置實(shí)例，針對 Apache， Lighttpd 以及 NGINX：https://raymii.org/s/articles/HTTPPublicKeyPinningExtension_HPKP.html
配置示例
 

如果你應(yīng)用了上面的配置文件，你需要重啟nginx:

現(xiàn)在使用SSL 實(shí)驗(yàn)室測試（SSL Labs tes）看看你是否得到一個(gè)漂亮的A。同時(shí)，當(dāng)然，擁有一個(gè)安全的，牢靠的，作為未來樣例的SSL配置。