nginx禁用des加密

1. 只是nginx 開啟 ssl 後端的 tomcat 不用 ssl，這樣有安全風險嗎

如果能確保nginx到Tomcat的網路鏈路是安全的，不會被監聽、篡改，可以不用ssl
如nginx和Tomcat位於安全可信的區域網內，二者通信可以不加密

2. 常見的幾種SSL/TLS漏洞及攻擊方式

SSL/TLS漏洞目前還是比較普遍的，首先關閉協議：SSL2、SSL3（比較老的SSL協議）配置完成ATS安全標准就可以避免以下的攻擊了，最新的伺服器環境都不會有一下問題，當然這種漏洞都是自己部署證書沒有配置好導致的。

Export 加密演算法

Export是一種老舊的弱加密演算法，是被美國法律標示為可出口的加密演算法，其限制對稱加密最大強度位數為40位，限制密鑰交換強度為最大512位。這是一個現今被強制丟棄的演算法。

Downgrade（降級攻擊）

降級攻擊是一種對計算機系統或者通信協議的攻擊，在降級攻擊中，攻擊者故意使系統放棄新式、安全性高的工作方式，反而使用為向下兼容而准備的老式、安全性差的工作方式，降級攻擊常被用於中間人攻擊，講加密的通信協議安全性大幅削弱，得以進行原本不可能做到的攻擊。 在現代的回退防禦中，使用單獨的信號套件來指示自願降級行為，需要理解該信號並支持更高協議版本的伺服器來終止協商，該套件是TLS_FALLBACK_SCSV(0x5600)

MITM（中間人攻擊）

MITM(Man-in-the-MiddleAttack) ，是指攻擊者與通訊的兩端分別創建獨立的聯系，並交換其所有收到的數據，使通訊的兩端認為他們正在通過一個私密的連接與對方直接對話，但事實上整個對話都被攻擊者完全控制，在中間人攻擊中，攻擊者可以攔截通訊雙方的通話並插入新的內容。一個中間人攻擊能成功的前提條件是攻擊者能夠將自己偽裝成每個參與會話的終端，並且不被其他終端識破。

BEAST（野獸攻擊）

BEAST(CVE-2011-3389) BEAST是一種明文攻擊，通過從SSL/TLS加密的會話中獲取受害者的COOKIE值（通過進行一次會話劫持攻擊），進而篡改一個加密演算法的 CBC（密碼塊鏈）的模式以實現攻擊目錄，其主要針對TLS1.0和更早版本的協議中的對稱加密演算法CBC模式。

RC4 加密演算法

由於早期的BEAST野獸攻擊而採用的加密演算法，RC4演算法能減輕野獸攻擊的危害，後來隨著客戶端版本升級，有了客戶端緩解方案（Chrome 和 Firefox 提供了緩解方案），野獸攻擊就不是什麼大問題了。同樣這是一個現今被強制丟棄的演算法。

CRIME（罪惡攻擊）

CRIME(CVE-2012-4929)，全稱Compression Ratio Info-leak Made Easy，這是一種因SSL壓縮造成的安全隱患，通過它可竊取啟用數據壓縮特性的HTTPS或SPDY協議傳輸的私密Web Cookie。在成功讀取身份驗證Cookie後，攻擊者可以實行會話劫持和發動進一步攻擊。

SSL 壓縮在下述版本是默認關閉的： nginx 1.1.6及更高/1.0.9及更高（如果使用了 OpenSSL 1.0.0及更高）， nginx 1.3.2及更高/1.2.2及更高（如果使用較舊版本的 OpenSSL）。

如果你使用一個早期版本的 nginx 或 OpenSSL，而且你的發行版沒有向後移植該選項，那麼你需要重新編譯沒有一個 ZLIB 支持的 OpenSSL。這會禁止 OpenSSL 使用 DEFLATE 壓縮方式。如果你禁用了這個，你仍然可以使用常規的 HTML DEFLATE 壓縮。

Heartbleed（心血漏洞）

Heartbleed(CVE-2014-0160) 是一個於2014年4月公布的 OpenSSL 加密庫的漏洞，它是一個被廣泛使用的傳輸層安全（TLS）協議的實現。無論是伺服器端還是客戶端在 TLS 中使用了有缺陷的 OpenSSL，都可以被利用該缺陷。由於它是因 DTLS 心跳擴展（RFC 6520）中的輸入驗證不正確（缺少了邊界檢查）而導致的，所以該漏洞根據「心跳」而命名。這個漏洞是一種緩存區超讀漏洞，它可以讀取到本不應該讀取的數據。如果使用帶缺陷的Openssl版本，無論是伺服器還是客戶端，都可能因此受到攻擊。

POODLE漏洞（捲毛狗攻擊）

2014年10月14號由Google發現的POODLE漏洞，全稱是Padding Oracle On Downloaded Legacy Encryption vulnerability，又被稱為「貴賓犬攻擊」（CVE-2014-3566），POODLE漏洞只對CBC模式的明文進行了身份驗證，但是沒有對填充位元組進行完整性驗證，攻擊者竊取採用SSL3.0版加密通信過程中的內容，對填充位元組修改並且利用預置填充來恢復加密內容，以達到攻擊目的。

TLS POODLE（TLS捲毛狗攻擊）

TLS POODLE(CVE-2014-8730) 該漏洞的原理和POODLE漏洞的原理一致，但不是SSL3協議。由於TLS填充是SSLv3的一個子集，因此可以重新使用針對TLS的POODLE攻擊。TLS對於它的填充格式是非常嚴格的，但是一些TLS實現在解密之後不執行填充結構的檢查。即使使用TLS也不會容易受到POODLE攻擊的影響。

CCS

CCS(CVE-2014-0224) 全稱openssl MITM CCS injection attack，Openssl 0.9.8za之前的版本、1.0.0m之前的以及1.0.1h之前的openssl沒有適當的限制ChangeCipherSpec信息的處理，這允許中間人攻擊者在通信之間使用0長度的主密鑰。

FREAK

FREAK(CVE-2015-0204) 客戶端會在一個全安全強度的RSA握手過程中接受使用弱安全強度的出口RSA密鑰，其中關鍵在於客戶端並沒有允許協商任何出口級別的RSA密碼套件。

Logjam

Logjam(CVE-2015-4000) 使用 Diffie-Hellman 密鑰交換協議的 TLS 連接很容易受到攻擊，尤其是DH密鑰中的公鑰強度小於1024bits。中間人攻擊者可將有漏洞的 TLS 連接降級至使用 512 位元組導出級加密。這種攻擊會影響支持 DHE_EXPORT 密碼的所有伺服器。這個攻擊可通過為兩組弱 Diffie-Hellman 參數預先計算 512 位元組質數完成，特別是 Apache 的 httpd 版本 2.1.5 到 2.4.7，以及 OpenSSL 的所有版本。

DROWN（溺水攻擊/溺亡攻擊）

2016年3月發現的針對TLS的新漏洞攻擊——DROWN（Decrypting RSA with Obsolete and Weakened eNcryption，CVE-2016-0800），也即利用過時的、弱化的一種RSA加密演算法來解密破解TLS協議中被該演算法加密的會話密鑰。 具體說來，DROWN漏洞可以利用過時的SSLv2協議來解密與之共享相同RSA私鑰的TLS協議所保護的流量。 DROWN攻擊依賴於SSLv2協議的設計缺陷以及知名的Bleichenbacher攻擊。

通常檢查以下兩點伺服器的配置

• 伺服器允許SSL2連接，需要將其關閉。

• 私鑰同時用於允許SSL2連接的其他伺服器。例如，Web伺服器和郵件伺服器上使用相同的私鑰和證書，如果郵件伺服器支持SSL2，即使web伺服器不支持SSL2，攻擊者可以利用郵件伺服器來破壞與web伺服器的TLS連接。

Openssl Padding Oracle

Openssl Padding Oracle(CVE-2016-2107) openssl 1.0.1t到openssl 1.0.2h之前沒有考慮某些填充檢查期間的內存分配，這允許遠程攻擊者通過針對AES CBC會話的padding-oracle攻擊來獲取敏感的明文信息。

強制丟棄的演算法

• aNULL 包含了非驗證的 Diffie-Hellman 密鑰交換，這會受到中間人（MITM）攻擊

• eNULL 包含了無加密的演算法（明文）

• EXPORT 是老舊的弱加密演算法，是被美國法律標示為可出口的

• RC4 包含的加密演算法使用了已棄用的 ARCFOUR 演算法

• DES 包含的加密演算法使用了棄用的數據加密標准（DES）

• SSLv2 包含了定義在舊版本 SSL 標准中的所有演算法，現已棄用

• MD5 包含了使用已棄用的 MD5 作為哈希演算法的所有演算法

3. SSL/TLS 受誡禮；SSL/TLS RC4 信息泄露的問題

該IP地址啟動了SSL證書，目前啟動RC4加密屬於不安全協議，所以需要禁止！

嘗試收到處理漏洞：

1. 禁止apache伺服器使用RC4加密演算法
   vi /etc/httpd/conf.d/ssl.conf
   修改為如下配置
   SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!RC4
   重啟apache服務

2. 關於nginx加密演算法

   1.0.5及以後版本，默認SSL密碼演算法是HIGH:!aNULL:!MD5

   0.7.65、0.8.20及以後版本，默認SSL密碼演算法是HIGH:!ADH:!MD5

   0.8.19版本，默認SSL密碼演算法是 ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM

   0.7.64、0.8.18及以前版本，默認SSL密碼演算法是ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP

   低版本的nginx或沒注釋的可以直接修改域名下ssl相關配置為

   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-AES

   256-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-GC

   M-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

   ssl_prefer_server_ciphers on;

   需要nginx重新載入服務

其它解決辦法：升級伺服器環境到最新版，重新配置伺服器SSL證書就可以直接解決，詳情聯系伺服器環境技術人員處理。

4. 如何在nginx伺服器部署ssl證書

1、創建SSL證書

1.1生產私鑰，openssl genrsa -des3 -out xn2.lqb.com.key 2048。此命令將生成2048位的RSA私鑰，使用DES3演算法，私鑰文件名可任意命名，在Nginx配置中指定文件路徑即可，會提示設定私鑰密碼，請設置密碼，並牢記。

[root@Monitorssl]#opensslgenrsa-des3-outxn2.lqb.com2048 GeneratingRSAprivatekey,2048bitlongmolus …………………………….+++ ……………………………………………….+++ eis65537(0x010001) Enterpassphraseforxn2.lqb.com: Verifying-Enterpassphraseforxn2.lqb.com:

1.2以上生產的key是有密碼的，如果把密碼去除，執行如下命令openssl rsa -in xn2.lqb.com -out xn2.lqb.com_nopwd.key

[root@Monitorssl]#ls xn2.lqb.com [root@Monitorssl]#opensslrsa-inxn2.lqb.com-outxn2.lqb.com_nopwd.key Enterpassphraseforxn2.lqb.com: writingRSAkey

1.3由已生產的私鑰生成證書請求文件CSR。openssl rsa -in xn2.lqb.com -out xn2.lqb.com_nopwd.key

[root@Monitorssl]#opensslrsa-inxn2.lqb.com-outxn2.lqb.com_nopwd.key Enterpassphraseforxn2.lqb.com: writingRSAkey [root@Monitorssl]#opensslreq-new-keyxn2.lqb.com-outxn2.lqb.com.csr Enterpassphraseforxn2.lqb.com: intoyourcertificaterequest. . , Ifyouenter』.』,thefieldwillbeleftblank. —– CountryName(2lettercode)[AU]:CN StateorProvinceName(fullname)[Some-State]:shanghai LocalityName(eg,city)[]:shanghai OrganizationName(eg,company)[InternetWidgitsPtyLtd]:xn2.lqb.com OrganizationalUnitName(eg,section)[]:IT CommonName(e.g.serverFQDNorYOURname)[]:xn2.lqb.com EmailAddress[]:[email protected] Pleaseenterthefollowing』extra』attributes Achallengepassword[]: Anoptionalcompanyname[]: [root@Monitorssl]#ls xn2.lqb.comxn2.lqb.com.csrxn2.lqb.com_nopwd.key

1.4.證書請求文件CSR文件必須有CA的簽名才能形成證書，可以將此CSR發給StartSSL(可免費)、verisign(一大筆錢)等地方由他來驗證。也可以自己做CA，自己給自己頒發證書。創建一個自己簽署的CA證書。openssl req -new -x509 -days 3650 -key xn2.lqb.com -out xn2.lqb.com.crt

[root@Monitorssl]#opensslreq-new-x509-days3650-keyxn2.lqb.com-outxn2.lqb.com.crt xn2.lqb.comxn2.lqb.com.csrxn2.lqb.com_nopwd.key [root@Monitorssl]#opensslreq-new-x509-days3650-keyxn2.lqb.com_nopwd.key-outxn2.lqb.com.crt intoyourcertificaterequest. . , Ifyouenter』.』,thefieldwillbeleftblank. —– CountryName(2lettercode)[AU]:CN StateorProvinceName(fullname)[Some-State]:Shanghai LocalityName(eg,city)[]:shanghai OrganizationName(eg,company)[InternetWidgitsPtyLtd]:lqb.com OrganizationalUnitName(eg,section)[]:IT CommonName(e.g.serverFQDNorYOURname)[]:xn2.lqb.com EmailAddress[]: [root@Monitorssl]#ls xn2.lqb.comxn2.lqb.com.crtxn2.lqb.com.csrxn2.lqb.com_nopwd.key

2、配置nginx虛擬主機文件

[root@Monitorssl]#vim../server.conf server{ listen80; server_namexn2.lqb.com; root/html/xn2; #rewrite^/(.*)$https:xn3.lqb.com/$1permanent; location/{ indexindex.html; #proxy_cachemycache; #proxy_cache_valid2003h; #proxy_cache_valid30130210m; #proxy_cache_validall1m; #proxy_cache_use_staleerrortimeouthttp_500http_502http_503; # #proxy_passhttp://192.168.180.9; #proxy_set_headerHost$host; #proxy_set_headerX-Real-IP$remote_addr; } location/images/ { indexindex.html; } } server{ listen*:443; server_namexn2.lqb.com; sslon;###位虛擬主機開啟ssl支持 ssl_certificate/usr/local/nginx/conf/server/ssl/xn2.lqb.com.crt;###為虛擬主機指定簽名證書文件 ssl_certificate_key/usr/local/nginx/conf/server/ssl/xn2.lqb.com_nopwd.key;###為虛擬主機指定私鑰文件 ##ssl_session_timeout5m;####客戶端能夠重復使用存儲在緩存中的會話參數時間 root/html/xn3; location/images/{ indexindex.html; } location/{ proxy_passhttp://192.168.180.23; proxy_set_headerHost$host; proxy_set_headerX-Real-IP$remote_addr; } }

5. 請教個nginx 配置SSL的問題

生成證書
可以通過以下步驟生成一個簡單的證書：
首先，進入你想創建證書和私鑰的目錄，例如：
$ cd /usr/local/nginx/conf
創建伺服器私鑰，命令會讓你輸入一個口令：
$ openssl genrsa -des3 -out server.key 1024
創建簽名請求的證書（CSR）：
$ openssl req -new -key server.key -out server.csr
在載入SSL支持的Nginx並使用上述私鑰時除去必須的口令：
$ cp server.key server.key.org
$ openssl rsa -in server.key.org -out server.key
配置nginx
最後標記證書使用上述私鑰和CSR：
$ openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
修改Nginx配置文件，讓其包含新標記的證書和私鑰：
server {
server_name YOUR_DOMAINNAME_HERE;
listen 443;
ssl on;
ssl_certificate /usr/local/nginx/conf/server.crt;
ssl_certificate_key /usr/local/nginx/conf/server.key;
}
重啟nginx。
這樣就可以通過以下方式訪問：
https://YOUR_DOMAINNAME_HERE
另外還可以加入如下代碼實現80埠重定向到443IT人樂園
server {
listen 80;
server_name ww.centos.bz;
rewrite ^(.*) https://$server_name$1 permanent;
}

6. 如何用Nginx快速搭建一個安全的微服務架構

教你如何用Nginx搭建一個安全的、快速的微服務架構
今天我們要談論微服務以及如何使用Nginx構建一個快速的、安全的網路系統。最後，我們將向您展示一個使用Fabric模式如何非常快速和輕松地構建一個微服務的demo。
在我們探討Fabric模式之前，我想談一談微服務並且從Nginx的角度來看這意味著什麼。
0：56 - 大轉變

微服務已經引起了應用程序架構的重大轉變。

當我第一次開始構建應用程序時，他們都是差不多的。幻燈片中所展示的單體架構也象徵了應用程序的構造方式。
目前存在著某種類型的虛擬機（VM），對我來說，就是通常的Java。在虛擬機中應用的功能組件以對象的形式存在，這些對象是在內存中相互通訊的，它們將來來回回處理並進行方法調用。偶爾，你會採用諸如通知等機制來接觸到其他系統以便獲取數據或傳遞信息。

有了微服務之後，應用程序如何構建的範式是完全不同的了。你的功能組件會從在同一個主機的內存中通過虛擬機相互通訊轉變到部署在容器中，並且使用Restful API調用通過HTTP來相互連接。
這是非常強大的，因為它賦予了你功能隔離。它為您提供了更細粒度的可伸縮性，並且你可以獲得更好地處理故障的彈性。很多情況下這是簡單的事實，你只需要使用HTTP進行跨網路調用。
現在，這種方法也有一些缺點。
一件軼事


我有一個暗黑的秘密，我是一個微軟的員工並且從事.Net開發已經很多年了。當我在那兒的時候，我搭建了一個他們的名為Showcase的視頻發布平台。
Showcase是一個用來將微軟內部發布的所有視頻發布到網上的工具。人們可以觀看這些視頻並進行學習，比如Microsoft Word的使用提示和技巧。這是一個非常受歡迎的平台，我們有很多人使用它，並且其中很多人都會在我們發布的視頻上發表評論。
Showcase從一開始就是一個.Net單體應用，隨著它日益受歡迎，我們決定應該將它更換為SOA架構。轉換是相對容易的。Visual Studio提供了本質上的翻轉開關的能力，也就是將你的DLL調用轉變為Restful API調用。隨著一些小的重構，我們能夠讓我們的代碼運行得相當好。我們也為這些評論和應用內的社區功能使用智能社區服務。
緊密的迴路問題


看起來我們是SOA可行的，在我們的首次測試中，一切都工作正常，直到我們將系統切換到我們的Staging環境並開始使用生產環境數據時，我們就會看到一些嚴重的問題。這些問題在在頁面上有很多評論。
這是一個非常受歡迎的平台，其中的一些頁面已經有多達2000條評論了。當我們深入這些問題時，我們意識到這些頁面需要花費一分鍾進行渲染的原因是因為智能社區服務首先需要填充用戶名，然後對每一個用戶名都需要發起一個對於用戶資料庫的網路調用來獲得用戶詳細信息並且填充在渲染頁面上。這是非常低效的，需要一到兩分鍾來渲染頁面，而在內存中進行通常只需要5到6秒鍾。
緩解


當我們經歷了發現和解決問題的過程後，我們最終通過一些措施來調整優化系統，比如對所有的請求進行分組。我們緩存了一些數據，最終我們優化了網路來真正的提高性能。
所以，這與微服務有什麼關系呢？對的，藉助於微服務，你基本上是採用SOA架構的，並且會將其放入超光速引擎中。在SOA架構中所有的對象都是包含在單個虛擬機中並且在其內部管理，在內存中相互通訊，而現在微服務中是使用HTTP進行數據交換的。
當這樣做沒有問題時，你會獲得很好的性能和線性可伸縮性。
Nginx能夠很好地與微服務工作


Nginx是一個你可以用來過渡到微服務的最佳工具之一。
關於Nginx和微服務的一些歷史。我們從一開始就參與了微服務運動，還是第一個從Docker Hub下載應用的，我們的客戶以及那些擁有一些世界上最大的微服務安裝量的最終用戶廣泛地在他們的基礎設施使用Nginx。
原因是Nginx很小、很快並且很可靠。
Nginx微服務參考架構


我們還致力於在Nginx內部使用微服務工作已經有一段時間了。這是一個我們已經搭建的程式化的Nginx微服務參考架構，目前正在AWS上運行。
我們擁有6個核心的微服務，它們都運行在Docker容器里。我們決定建立一個多語種的應用，所以每個容器都可以運行不同的語言，我們目前使用了Ruby、Python、PHP、Java和Node.js。
我們搭建了這個使用十二要素應用的系統，稍加修改，就會使其更好地為微服務工作從而可以替代Roku平台。稍後，我們將向您展示一個實際上運行在demo里的應用。
MRA的價值


為什麼我們要建立這樣一個參考的微服務架構呢？
我們建立這個參考架構是因為我們需要給我們的客戶提供構建微服務的藍圖，我們也想在微服務上下文中測試Nginx和Nginx Plus的功能，弄清楚如何才能更好地利用它的優勢。最後，我們要確保我們對於微服務生態系統以及其可以給我們提供什麼有一個深入的理解。
網路問題


讓我們回到我們討論的大轉變。
從將運行在內存里並且被虛擬機管理的你的應用的所有功能組件遷移到通過網路進行工作並且相互通訊的方式，你會本質上引入一系列為了應用有效工作需要你解決的問題。
第一你需要服務發現，第二，你需要在架構中為所有不同的實例進行負載均衡，然後還有第三個，你需要操心性能和安全。
無論是好是壞，這些問題密不可分，你必須做權衡，有希望的是我們有一個可以解決所有這些問題的解決方案。
讓我們更深入地看待每一個問題。
服務發現

讓我們來談談服務發現。在單體應用中，APP引擎會管理所有的對象關系，你永遠不必擔心一個對象與另一個對象的相對位置，你只需要簡單的調用一個方法，虛擬機會連接到對象實例，然後在調用完畢後銷毀。
然後有了微服務，你需要考慮那些服務的位置。不幸的是，這不是一個普遍的標准流程。您正在使用的各種服務注冊中心，無論是Zookeeper、Consul、etcd或者其它的，都會以不同的方式進行工作。在這個過程中，你需要注冊你的服務，還需要能夠讀取這些服務在哪裡並且可以被連接。
負載均衡


第二個問題是關於負載均衡的。當您擁有多個服務實例時，您希望能夠輕松地連接到它們，將您的請求在它們中高效地分發，並以最快的方式執行，所以不同實例之間的負載均衡是非常重要的問題。
不幸的是，最簡單形式的負載均衡是非常低效的。當你開始使用不同的更加復雜的方案做負載均衡時，它也變得更加復雜並且不易於管理。理想情況下，您希望您的開發人員能夠基於他們的應用程序的需求決定何種負載均衡方案。例如，如果你連接到一個有狀態的應用程序，你需要擁有持久化，這樣可以確保你的Session信息會被保留。
安全和快速通訊


也許微服務最令人生畏的領域是性能和安全。
當在內存中運行時，一切都很快。現在，運行在網路上就會慢了一個數量級。
被安全地包含在一個系統中的信息，通常是二進制格式的，現在會被用文本格式在網路上傳輸。現在是比較容易在網路上布置嗅探器並能夠監聽你的應用正在被移動的所有數據。
如果要在傳輸層加密數據，那麼會在連接速率和CPU使用率方面引入顯著的開銷。SSL/TLS在其全面實施階段需要九個步驟來初始化一個請求。當你的系統每天需要處理成千上萬、幾萬、數十萬或數百萬的請求時，這就成為性能的一個重要障礙了。
一個解決方案


我們已經在Nginx開發的一些解決方案，我們認為，會解決所有的這些問題，它賦予你健壯的服務發現、非常棒的用戶可配置負載均衡以及安全和快速加密。
網路架構


讓我們來談談你可以安裝和配置你的網路架構的各種方法。
我們提出了三種網路模型，它們本身並不相互排斥，但我們認為它們屬於多種格式的。這三種模式是Proxy模式、Router Mesh模式和Fabric模式——這是最復雜的，並在許多方面在其頭部進行負載均衡。
Proxy模式


Proxy模式完全聚焦於你的微服務應用的入站流量，並且事實上忽略內部通訊。
你會獲得Nginx提供的所有的HTTP流量管理方面的福利。你可以有SSL/TLS終止、流量整形和安全，並且藉助於最新版本的Nginx Plus和ModSecurity，你可以獲得WAF能力。
你也可以緩存，你可以將Nginx提供給你的單體應用的所有東西添加到你的微服務系統里，並且藉助於Nginx Plus，你可以實現服務發現。當你的API實例上下浮動時，Nginx Plus可以在負載均衡工具里動態地添加和減去它們。
Router Mesh模式


Router Mesh模式類似於Proxy模式，在其中我們有一個前端代理服務來管理接入流量，但它也在服務之間添加了集中式的負載均衡。
每個服務連接到集中式的Router Mesh，它管理不同服務之間的連接分發。Router Mesh模式還允許你在熔斷器模式中搭建，以便可以對你的應用添加彈性並允許你採取措施來監控和拉回你的失效的服務實例。
不幸的是，因為該模式增加了一個額外的環節，如果你不得不進行SSL/TLS加密，它事實上加劇了性能問題。這就是引入Fabric模式的原因。
Fabric模式


Fabric模式是將其頭部的所有東西翻轉的模式。
就像之前的另外兩個模式一樣，在前面會有一個代理伺服器來管理流入流量，但與Router Mesh模式不同的地方就是你用運行在每個容器里的Nginx Plus來替代了集中式的Router。
這個Nginx Plus實例對於所有的HTTP流量作為反向和正向代理，使用這個系統，你可以獲得服務發現、健壯的負載均衡和最重要的高性能加密網路。
我們將探討這是如何發生的，以及我們如何處理這項工作。讓我們先來看看一個服務如何連接和分發他們的請求結構的正常流程。
正常的流程


在這個圖中，你可以看到投資管理器需要跟用戶管理器通訊來獲取信息。投資管理器創建了一個HTTP客戶端，該客戶端針對服務注冊中心發起了一個DNS請求並獲得返回的一個IP地址，接著初始化了一個到用戶管理器的SSL/TLS連接，該連接需要通過九階段的協商或者是」握手」過程。一旦數據傳輸完畢，虛擬機會關閉連接並進行HTTP客戶端的垃圾回收。
整個過程就是這樣。這是相當簡單和易於理解的。當你把它分解成這些步驟時，您可以看到該模式是如何真正完成請求和響應過程的。
在Fabric模式中，我們已經改變了這一點。
Fabric模式的細節


你會注意到的第一件事是Nginx Plus是運行在每一個服務里的，並且應用程序代碼是在本地與Nginx Plus通信的。因為這些是本地連接，你不需要擔心加密問題。它們可以是從Java或者PHP代碼到Nginx Plus實例的HTTP請求，並且都是在容器內的本地HTTP請求。
你也注意到Nginx Plus會管理到服務注冊中心的連接，我們有一個解析器，通過非同步查詢注冊中心的DNS實例來獲取所有的用戶管理器實例，並且預先建立連接，這樣當Java服務需要從用戶管理器請求一些數據的時候，可以使用預先建立的連接。
持久的SSL/TLS連接


微服務之間的有狀態的、持久化的並且可以加密的連接是真正的益處。
記得在第一個圖中服務實例是如何通過一些流程的吧，比如創建HTTP客戶端、協商SSL/TLS連接、發起請求並關閉的嗎？在這里，Nginx預先建立了微服務之間的連接，並使用Keepalive特性，保持調用之間的持續連接，這樣你就不必為每一個請求處理SSL/TLS協商了。
本質上，我們創建了一個迷你的從服務到服務的VPN連接。在我們最初的測試中，我們發現連接速度增加了77%。
熔斷器Plus


在Fabric模式以及Router Mesh模式中，你也可以從創建和使用熔斷器模式中獲得好處。
本質上，您定義了一個在服務內部的活躍的健康檢查，並設置緩存，以便在服務不可用的情況下保留數據，從而獲得完整的熔斷器功能。
所以，現在我可以確定你認為Fabirc模式聽起來很酷，並且想在實際環境中躍躍欲試。

7. nginx強制使用https是否能保證網站的安全

只能保證客戶端和伺服器端數據傳輸的安全。使用Https加密協議訪問網站，可激活客戶端瀏覽器到網站伺服器之間的"SSL加密通道"（SSL協議），實現高強度雙向加密傳輸，防止傳輸數據被泄露或篡改。詳細介紹：https://www.wosign.com/procts/ssl.htm

8. 如何部署linux下nginx的ssl數字證書

Nginx安裝SSL證書：網頁鏈接

Nginx 自動跳轉到HTTPS：網頁鏈接

SSL證書技術支持：網頁鏈接

注意：安裝防火牆需要設置允許443埠或關閉防火牆，如果本地伺服器安裝安全狗的，請允許443埠。

9. Nginx啟動期做了哪些事

它有1個master進程，和多個worker進程（最優配置的數量與CPU核數相關）。那麼，首先我們要找到main函數，它在src/core/nginx.c文件中。談到源碼了，這時我們先簡單看下源碼的目錄結構吧。
nginx主要有下列目錄：
src/core，這個目錄存放了基礎的數據結構像LIST、紅黑樹、nginx字元串，貫穿始終的一些邏輯結構如ngx_cycle_s、ngx_connection_s等，還有對一些底層操作的封裝如log、文件操作、共享內存、內存池等，最後還有個nginx.c這個main啟動函數了。
src/event，這個目錄下存放與抽象事件相關的結構和鉤子函數。nginx是以事件驅動處理流程的，事件自然是整個體系的核心了，這里定義了最核心的ngx_event_s結構。
src/event/moles目錄存放了具體的種種事件驅動方式，例如epoll、kqueue、poll、aio、select等，它們通過ngx_event_actions_t結構體中的鉤子掛在nginx中。nginx啟動時會根據配置來決定使用哪種實現方式。
src/os/unix中存放了unix系統下許多函數調用的UNIX實現。
src/http目錄存放到http mole的相關實現，這個mole負責處理http請求，包括協議的解析以及訪問backend server的代碼。
src/http/mole目錄存放http mole類型的一些特定用途的mole，比如gzip處理加密，圖片壓縮等。
有個初步了解後，回到main函數中，順序看看我們感興趣的事情。它先執行了ngx_time_init，為什麼要初始化時間呢？nginx考慮的還是很周到的，取系統時間gettimeofday是系統調用，這意味著，需要發送中斷給linux內核，內核需要做進程間切換來處理這個調用。這是一個不能忽視成本的函數。nginx封裝了時間函數，這樣，每次我們需要處理時間時，並不是調用gettimeofday，而是nginx自己緩存的時間，這樣大量減少了系統調用，取當前時間這事可是誰都愛乾的。
那麼，nginx是怎麼維護自己的這個時鍾呢？如何保證用戶取到的當前時間是有意義的？nginx設計者的出發點是，nginx是事件驅動機制，當一批事件發生時，也就是epoll_wait返回時，會取一次gettimeofday來更新自己的時間，然後調用各個事件對應的處理函數。這些函數都會保證自己是無阻塞的，也就是毫秒級的處理能力，所以，在任何一個事件處理函數中，取到的時間都是之前epoll_wait剛返回時取到的時間，這樣，即使拿到的時間慢了幾毫秒也無所謂。關鍵是，每個函數都是無阻塞的，都要迅速的把控制權交還給nginx，這是基本設計原則哈。
main函數初始化時間後，建立了最核心的數據結構ngx_cycle，之後無論是worker進程還是master進程都是圍繞著它進行的。下面，我們要超級關注ngx_init_cycle這個函數，啟動過程中大量的工作是在這完成的，代碼就不列了，這個函數有800行，超大，也可見其之關鍵。ngx_init_cycle里做的第一件事就是調用所有nginx mole里的create_conf方法。好，現在我們才來詳細看下nginx mole是什麼。
nginx 抽象出一個ngx_mole_s結構用來描述各個mole，每個mole處理它感興起的事件。nginx里共有多少個mole既是寫死在代碼中的，也是可以靈活配置的，呵呵，nginx式的玩法。回想下，下載nginx源碼包後，我們也要執行它提供的configure操作，這個命令會生成makefile和ngx_moles文件，makefilel決定編譯哪些mole源文件，而生成的ngx_moles.c文件決定編譯出的執行文件究竟使用哪些mole。ngx_moles.c裡面會生成一個數組ngx_moles，這是整個nginx工程都在使用的全局變數，它的形式如下：[cpp]ngx_mole_t*ngx_moles[]={
&ngx_core_mole,
&ngx_errlog_mole,
&ngx_conf_mole,
接上文，ngx_init_cycle就是通過ngx_moles數組來調用所有mole的create_conf方法的（每個mole有權力決定是否實現這個方法，如果不實現的話，當然不會調用了）。然後，開始處理配置文件，這里我們需要重點關注ngx_conf_parse函數，因為它裡面調用了ngx_conf_handler方法，ngx_conf_handler方法會調用每個mole里自己實現的set鉤子函數，讓每個mole處理自己感興趣的配置項。所以，如果你在nginx.conf里沒有配置某個mole想要的東東，這個mole雖然編譯進去了，卻會一直不執行的。這里我們要看下mole的結構了，不能總是干說哈。
[cpp]structngx_mole_s{
ngx_uint_tctx_index;
ngx_uint_tindex;
......void*ctx;ngx_command_t*commands;
ngx_uint_ttype;
ngx_int_t(*init_master)(ngx_log_t*log);
ngx_int_t(*init_mole)(ngx_cycle_t*cycle);
ngx_int_t(*init_process)(ngx_cycle_t*cycle);

10. 怎麼看自己伺服器的SSL服務使用的協議版本和加密演算法

SSL協議是一種安全傳輸協議，SSL是SecureSocketLayer的縮寫，即安全套接層協議。該協議最初由Netscape企業發展而來，目前已經成為互聯網上用來鑒別網站和網頁瀏覽者的身份，以及在瀏覽器使用者及網頁伺服器之間進行加密通訊的全球化標准協議。由於SSL技術已建立到了所有主要的瀏覽器和WEB伺服器程序當中，因此，僅需安裝數字證書，或伺服器證書就可以激活伺服器功能了。 SSL協議能夠對信用卡和個人信息提供較安全的保護。SSL是對計算機之間整個會話進行加密的協議。在SSL中，採用了公開密鑰和私有密鑰兩種加密方法。 SSL協議的優勢在於它是應用層協議確立無關的。高層的應用協議如HTTP、FTP、Telnet等能透明地建立於SSL協議之上。其在應用層協議通信之前就已經完成加密演算法、通信密鑰的協商以及伺服器認證工作。在此之後應用層協議所傳送的數據都會被加密，從而保證我們在互聯網上通信的安全。 SSL協議提供的安全服務有: 1)認證用戶和伺服器，確保數據發送到正確的客戶機和伺服器; 2)加密數據以防止數據中途被竊取; 3)維護數據的完整性，確保數據在傳輸過程中不被改變。 SSL的主要目的是在兩個通信應用程序之間提供私密信和可靠性。這個過程通過3個元素來完成: 1、握手協議。 握手協議負責協商被用於客戶機和伺服器之間會話的加密參數。當一個SSL客戶機和伺服器第一次開始通信時，它們在一個協議版本上達成一致，選擇加密演算法，選擇相互認證，並使用公鑰技術來生成共享密鑰。 2、記錄協議。 記錄協議用於交換應用層數據。應用程序消息被分割成可管理的數據塊，還可以壓縮，並應用一個MAC(消息認證代碼);然後結果被加密並傳輸。接受方接受數據並對它解密，校驗MAC，解壓縮並重新組合它，並把結果提交給應用程序協議。 3、警告協議。這個協議用於指示在什麼時候發生了錯誤或兩個主機之間的會話在什麼時候終止。 下面我們來看一個使用WEB客戶機和伺服器的範例。WEB客戶機通過連接到一個支持SSL的伺服器，啟動一次SSL會話。支持SSL的典型WEB伺服器在一個與標准HTTP請求(默認為埠80)不同的埠(默認為443)上接受SSL連接請求。當客戶機連接到這個埠上時，它將啟動一次建立SSL會話的握手。當握手完成之後，通信內容被加密，並且執行消息完整性檢查，知道SSL會話過期。SSL創建一個會話，在此期間，握手必須只發生過一次。當SSL會話過程中出現了問題或埠設置出了問題，就會造成無法使用SSL連接現象。 SSL握手過程步驟: 步驟1:SSL客戶機連接到SSL伺服器，並要求伺服器驗證它自身的身份。 步驟2:伺服器通過發送它的數字證書證明其身份。這個交換還可以包括整個證書鏈，直到某個根證書權威機構(CA)。通過檢查有效日期並確認證書包含有可信任CA的數字簽名，來驗證證書。 步驟3:伺服器發出一個請求，對客戶端的證書進行驗證。但是，因為缺乏公鑰體系結構，當今的大多數伺服器不進行客戶端認證。 步驟4:協商用於加密的消息加密演算法和用於完整性檢查的哈希函數。通常由客戶機提供它支持的所有演算法列表，然後由伺服器選擇最安全的加密演算法。 步驟5:客戶機和伺服器通過下列步驟生成會話密鑰: a. 客戶機生成一個隨機數，並使用伺服器的公鑰(從伺服器的證書中獲得)對它加密，然後發送到伺服器上 b. 伺服器用更加隨機的數據(從客戶機的密鑰可用時則使用客戶機密鑰;否則以明文方式發送數據)響應。 c. 使用哈希函數，從隨機數據生成安全密鑰。 SSL協議的優點是它提供了連接安全，具有3個基本屬性: l 連接是私有的。在初始握手定義了一個密鑰之後，將使用加密演算法。對於數據加密使用了對稱加密(例如DES和RC4)。 l 可以使用非對稱加密或公鑰加密(例如RSA和DSS)來驗證對等實體的身份。 l 連接時可靠的。消息傳輸使用一個密鑰的MAC，包括了消息完整性檢查。其中使用了安全哈希函數(例如SHA和MD5)來進行MAC計算。 對於SSL的接受程度僅僅限於HTTP內。它在其他協議中曾被表明可以使用，但還沒有被廣泛應用。收藏本文章下載本文章(DOC格式)下載本文章(TXT格式)