欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Nginx服務(wù)器中關(guān)于SSL的安全配置詳解

 更新時(shí)間：2015年06月26日 10:58:24   投稿：goldensun  
這篇文章主要介紹了Nginx服務(wù)器中關(guān)于SSL的安全配置詳解,2014年曝出的SSL安全漏洞無疑為整個(gè)業(yè)界帶來了巨大震動(dòng),本文便對(duì)此給出相關(guān)安全維護(hù)方法,需要的朋友可以參考下

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

我們?cè)趎ginx的設(shè)置文檔中如下編輯

復(fù)制代碼 代碼如下:
/etc/nginx/sited-enabled/yoursite.com (On Ubuntu/Debian)
或者在

復(fù)制代碼 代碼如下:
/etc/nginx/conf.d/nginx.conf (On RHEL/CentOS).

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

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

BEAST攻擊和RC4算法

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

新版本的瀏覽器客戶端可以緩解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ù)器會(huì)因?yàn)檫@樣的用戶開銷更大。二、RC4可以緩解BEAST攻擊。因此，禁用RC4使TLS 1用戶容易受到攻擊，通過移動(dòng)他們AES-CBC（通常的服務(wù)器端的BEAST“修復(fù)”是優(yōu)先考慮高于一切的RC4）。我很確信，在BEAST上RC4上的缺陷明顯大于風(fēng)險(xiǎn)。確實(shí)，客戶端的緩解（chrome和火狐都提供）BEAST已不再是個(gè)問題。但對(duì)于增長(zhǎng)RC4的風(fēng)險(xiǎn)：隨著時(shí)間的推移更多的密碼分析將很表面化。

FREAK攻擊

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

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

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

MITM攻擊過成如下：

  •     在客戶端的Hello消息中，它請(qǐng)求一個(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è)頁(yè)面上提供密碼套件但是支持密碼輸出等級(jí)。確保你的OpenSSl是最近更新過的版本而且你的客戶端也要使用最新的軟件。

Heartbleed(心臟出血)

Hearbleed是一個(gè)在2014年四月OpenSSL密碼庫(kù)里被發(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號(hào)發(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è)降級(jí)攻擊時(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降級(jí)。以下是升級(jí)后自動(dòng)啟用的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 及更高的版本.

更多的信息請(qǐng)參閱NGINX文檔
密碼套件

Forward Secrecy 確保了在永久密鑰被泄漏的事件中，會(huì)話密鑰的完整性。PFS 實(shí)現(xiàn)這些是通過執(zhí)行推導(dǎo)每個(gè)會(huì)話的新密鑰來完成。

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

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


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

推薦的密碼套件:
 

復(fù)制代碼 代碼如下:

ssl_ciphers 'AES128+EECDH:AES128+EDH';

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

復(fù)制代碼 代碼如下:

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 是舊版本，不可用密碼將被自動(dòng)丟棄?？偸鞘褂猛暾拿艽a套件，讓OpenSSL選它所支持的。

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

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

優(yōu)先級(jí)邏輯

  •     首先選擇 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 被美國(guó)法律標(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)添加了以下幾行：
 

復(fù)制代碼 代碼如下:

ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;

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

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

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

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

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


1.4.4所有的nginx版本在往Diffiel-Hellman輸入?yún)?shù)時(shí)依賴OpenSSL。不幸的時(shí)，這就意味著Ephemeral Diffiel-Hellman（DHE）會(huì)使用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í)候使用它：
 

復(fù)制代碼 代碼如下:

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

OCSP 適用

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


OCSP是更輕量級(jí)的，因?yàn)樗淮沃猾@取一條記錄。但是副作用是，當(dāng)連接到服務(wù)器的時(shí)候，OCSP請(qǐng)求必須發(fā)送到第三方響應(yīng)者，這增加了延遲，以及失敗的可能。實(shí)際上，OCSP響應(yīng)者由CA操控，由于它常常不可靠，導(dǎo)致瀏覽器由于收不到適時(shí)的響應(yīng)而失敗。這減少了安全性，因?yàn)樗试S攻擊者對(duì)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ù)器只在客戶端請(qǐng)求的時(shí)候，發(fā)送一個(gè)緩存的OCSP響應(yīng)，通過對(duì)CLIENT HELLO的status_request TLS拓展來聲明支持。

大多數(shù)服務(wù)器都會(huì)緩存OCSP響應(yīng)到48小時(shí)。在常規(guī)間隔，服務(wù)器會(huì)連接到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可以對(duì)*.example.com進(jìn)行簽名，而不是瀏覽器中保存的任何一個(gè)CA。

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

復(fù)制代碼 代碼如下:

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;
 
}

結(jié)論

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

復(fù)制代碼 代碼如下:
# Check the config first:
/etc/init.d/nginx configtest
# Then restart:
/etc/init.d/nginx restart

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

相關(guān)文章

  • 使用Nginx限制IP請(qǐng)求和并發(fā)連接數(shù)的實(shí)現(xiàn)方法

    使用Nginx限制IP請(qǐng)求和并發(fā)連接數(shù)的實(shí)現(xiàn)方法

    本文主要介紹了使用Nginx限制IP請(qǐng)求和并發(fā)連接數(shù)的實(shí)現(xiàn)方法,通過使用Nginx的限制模塊,我們可以輕松地實(shí)現(xiàn)對(duì)IP請(qǐng)求和并發(fā)連接數(shù)的限制,具體就跟小編一起來了解一下
    2024-03-03
  • nginx部署后css、js、圖片等樣式不加載問題的兩種解決方案

    nginx部署后css、js、圖片等樣式不加載問題的兩種解決方案

    這篇文章主要介紹了nginx部署后css、js、圖片等樣式不加載問題的兩種解決方案,本文給大家介紹的非常詳細(xì),具有一定的參考借鑒價(jià)值,需要的朋友可以參考下
    2023-12-12
  • nginx部署前端項(xiàng)目的超級(jí)詳細(xì)步驟記錄

    nginx部署前端項(xiàng)目的超級(jí)詳細(xì)步驟記錄

    眾所周知Nginx是一款高性能的http服務(wù)器/反向代理服務(wù)器及電子郵件(IMAP/POP3)代理服務(wù)器,這篇文章主要給大家介紹了關(guān)于nginx部署前端項(xiàng)目的超級(jí)詳細(xì)步驟,需要的朋友可以參考下
    2023-02-02
  • Nginx反向代理location和proxy_pass配置規(guī)則詳細(xì)總結(jié)

    Nginx反向代理location和proxy_pass配置規(guī)則詳細(xì)總結(jié)

    nginx代理訪問很好用,但是好多人不清楚location和proxy_pass組合在一起使用時(shí)訪問的url被代理的url真實(shí)地址是什么,下面這篇文章主要給大家介紹了關(guān)于Nginx反向代理location和proxy_pass配置規(guī)則的相關(guān)資料,需要的朋友可以參考下
    2022-09-09
  • CentOS 4.0安裝配置Nginx的方法

    CentOS 4.0安裝配置Nginx的方法

    這篇文章主要介紹了CentOS 4.0安裝配置Nginx的方法,需要的朋友可以參考下
    2014-11-11
  • 使用nginx配置基于域名的虛擬主機(jī)實(shí)現(xiàn)​

    使用nginx配置基于域名的虛擬主機(jī)實(shí)現(xiàn)​

    這篇文章主要介紹了nginx配置基于域名的虛擬主機(jī)實(shí)現(xiàn)​，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2019-10-10
  • Nginx進(jìn)程殺不完的解決方法

    Nginx進(jìn)程殺不完的解決方法

    這篇文章主要給大家介紹了Nginx進(jìn)程殺不完的解決方法,文中通過圖文結(jié)合的方式給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作有一定的幫助,,需要的朋友可以參考下
    2023-12-12
  • 利用nginx+lua+redis實(shí)現(xiàn)反向代理方法教程

    利用nginx+lua+redis實(shí)現(xiàn)反向代理方法教程

    這篇文章主要給大家介紹了利用nginx+lua+redis實(shí)現(xiàn)反向代理方法教程，文中介紹的非常詳細(xì)，對(duì)大家具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來一起看看吧。
    2017-05-05
  • 使用nginx模擬進(jìn)行藍(lán)綠部署的方式

    使用nginx模擬進(jìn)行藍(lán)綠部署的方式

    今天小編就為大家分享一篇關(guān)于使用nginx模擬進(jìn)行藍(lán)綠部署的方式，小編覺得內(nèi)容挺不錯(cuò)的，現(xiàn)在分享給大家，具有很好的參考價(jià)值，需要的朋友一起跟隨小編來看看吧
    2018-12-12
  • nginx緩存以及清除緩存的使用

    nginx緩存以及清除緩存的使用

    本文主要介紹了nginx緩存以及清除緩存的使用，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧
    2022-07-07

最新評(píng)論