nginx配置ssl加密(单双向认证、部分https)
nginx下配置ssl本來是很簡(jiǎn)單的,無論是去認(rèn)證中心買SSL安全證書還是自簽署證書,但最近公司OA的一個(gè)需求,得以有個(gè)機(jī)會(huì)實(shí)際折騰一番。一開始采用的是全站加密,所有訪問http:80的請(qǐng)求強(qiáng)制轉(zhuǎn)換(rewrite)到https,后來自動(dòng)化測(cè)試結(jié)果說響應(yīng)速度太慢,https比http慢慢30倍,心想怎么可能,鬼知道他們?cè)趺礈y(cè)的。所以就試了一下部分頁面https(不能只針對(duì)某類動(dòng)態(tài)請(qǐng)求才加密)和雙向認(rèn)證。下面分節(jié)介紹。
默認(rèn)nginx是沒有安裝ssl模塊的,需要編譯安裝nginx時(shí)加入--with-http_ssl_module選項(xiàng)。
關(guān)于SSL/TLS原理請(qǐng)參考?這里,如果你只是想測(cè)試或者自簽發(fā)ssl證書,參考?這里?。
提示:nignx到后端服務(wù)器由于一般是內(nèi)網(wǎng),所以不加密。
1. 全站ssl
全站做ssl是最常見的一個(gè)使用場(chǎng)景,默認(rèn)端口443,而且一般是單向認(rèn)證。
server?{listen?443;server_name?example.com;root?/apps/www;index?index.html?index.htm;ssl?on;ssl_certificate?../SSL/ittest.pem;ssl_certificate_key?../SSL/ittest.key;#????????ssl_protocols?SSLv3?TLSv1?TLSv1.1?TLSv1.2; #????????ssl_ciphers?ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP; #????????ssl_prefer_server_ciphers?on;}如果想把http的請(qǐng)求強(qiáng)制轉(zhuǎn)到https的話:
server?{listen??????80;server_name?example.me;rewrite?????^???https://$server_name$request_uri??permanent;###?使用return的效率會(huì)更高? #??return?301?https://$server_name$request_uri; }ssl_certificate證書其實(shí)是個(gè)公鑰,它會(huì)被發(fā)送到連接服務(wù)器的每個(gè)客戶端,ssl_certificate_key私鑰是用來解密的,所以它的權(quán)限要得到保護(hù)但nginx的主進(jìn)程能夠讀取。當(dāng)然私鑰和證書可以放在一個(gè)證書文件中,這種方式也只有公鑰證書才發(fā)送到client。
ssl_protocols指令用于啟動(dòng)特定的加密協(xié)議,nginx在1.1.13和1.0.12版本后默認(rèn)是ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2,TLSv1.1與TLSv1.2要確保OpenSSL >= 1.0.1 ,SSLv3 現(xiàn)在還有很多地方在用但有不少被×××的漏洞。
ssl_ciphers選擇加密套件,不同的瀏覽器所支持的套件(和順序)可能會(huì)不同。這里指定的是OpenSSL庫能夠識(shí)別的寫法,你可以通過?openssl -v cipher 'RC4:HIGH:!aNULL:!MD5'(后面是你所指定的套件加密算法) 來看所支持算法。
ssl_prefer_server_ciphers on設(shè)置協(xié)商加密算法時(shí),優(yōu)先使用我們服務(wù)端的加密套件,而不是客戶端瀏覽器的加密套件。
https優(yōu)化參數(shù)
ssl_session_cache shared:SSL:10m;?: 設(shè)置ssl/tls會(huì)話緩存的類型和大小。如果設(shè)置了這個(gè)參數(shù)一般是shared,buildin可能會(huì)參數(shù)內(nèi)存碎片,默認(rèn)是none,和off差不多,停用緩存。如shared:SSL:10m表示我所有的nginx工作進(jìn)程共享ssl會(huì)話緩存,官網(wǎng)介紹說1M可以存放約4000個(gè)sessions。 詳細(xì)參考serverfault上的問答ssl_session_cache。
ssl_session_timeout?: 客戶端可以重用會(huì)話緩存中ssl參數(shù)的過期時(shí)間,內(nèi)網(wǎng)系統(tǒng)默認(rèn)5分鐘太短了,可以設(shè)成30m即30分鐘甚至4h。
設(shè)置較長(zhǎng)的keepalive_timeout也可以減少請(qǐng)求ssl會(huì)話協(xié)商的開銷,但同時(shí)得考慮線程的并發(fā)數(shù)了。
提示:在生成證書請(qǐng)求csr文件時(shí),如果輸入了密碼,nginx每次啟動(dòng)時(shí)都會(huì)提示輸入這個(gè)密碼,可以使用私鑰來生成解密后的key來代替,效果是一樣的,達(dá)到免密碼重啟的效果:
導(dǎo)入證書
如果你是找一個(gè)知名的ssl證書頒發(fā)機(jī)構(gòu)如VeriSign、Wosign、StartSSL簽發(fā)的證書,瀏覽器已經(jīng)內(nèi)置并信任了這些根證書,如果你是自建C或獲得二級(jí)CA授權(quán),都需要將CA證書添加到瀏覽器,這樣在訪問站點(diǎn)時(shí)才不會(huì)顯示不安全連接。各個(gè)瀏覽的添加方法不在本文探討范圍內(nèi)。
2. 部分頁面ssl
一個(gè)站點(diǎn)并不是所有信息都是非常機(jī)密的,如網(wǎng)上商城,一般的商品瀏覽可以不通過https,而用戶登錄以及支付的時(shí)候就強(qiáng)制經(jīng)過https傳輸,這樣用戶訪問速度和安全性都得到兼顧。
但是請(qǐng)注意不要理解錯(cuò)了,是對(duì)頁面加密而不能針對(duì)某個(gè)請(qǐng)求加密,一個(gè)頁面或地址欄的URL一般會(huì)發(fā)起許多請(qǐng)求的,包括css/png/js等靜態(tài)文件和動(dòng)態(tài)的java或php請(qǐng)求,所以要加密的內(nèi)容包含頁面內(nèi)的其它資源文件,否則就會(huì)出現(xiàn)http與https內(nèi)容混合的問題。在http頁面混有https內(nèi)容時(shí),頁面排版不會(huì)發(fā)生亂排現(xiàn)象;在https頁面中包含以http方式引入的圖片、js等資源時(shí),瀏覽器為了安全起見會(huì)阻止加載。
下面是只對(duì)example.com/account/login登錄頁面進(jìn)行加密的栗子:
root?/apps/www; index?index.html?index.htm;server?{listen??????80;server_name?example.com;location?^~?/account/login?{rewrite?^?https://$server_name:443$request_uri??permanent;}location?/?{proxy_pass??http://localhost:8080;###?Set?headers?####proxy_set_header?Host?$host;proxy_set_header?X-Real-IP?$remote_addr;proxy_set_header?X-Forwarded-For?$proxy_add_x_forwarded_for;proxy_redirect?????off;?} }server?{listen?443?ssl;server_name?example.com;ssl?on;ssl_certificate?../SSL/ittest.pem;ssl_certificate_key?../SSL/ittest.key;ssl_protocols?SSLv3?TLSv1?TLSv1.1?TLSv1.2;ssl_ciphers?ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;ssl_prefer_server_ciphers?on;location?^~?/account/login?{proxy_pass??http://localhost:8080;proxy_set_header?Host?$host;proxy_set_header?X-Real-IP?$remote_addr;proxy_set_header?X-Forwarded-For?$proxy_add_x_forwarded_for;proxy_redirect?????off;?###?Most?PHP,?Python,?Rails,?Java?App?can?use?this?header?->?https?###proxy_set_header?X-Forwarded-Proto??$scheme;}location?/?{rewrite??^??http://$server_name$request_uri??permanent;} }關(guān)于rewrite與location的寫法參考這里。當(dāng)瀏覽器訪問http://example.com/account/login.xx時(shí),被301到https://example.com/account/login.xx,在這個(gè)ssl加密的虛擬主機(jī)里也匹配到/account/login,反向代理到后端服務(wù)器,后面的傳輸過程是沒有https的。這個(gè)login.xx頁面下的其它資源也是經(jīng)過https請(qǐng)求nginx的,登錄成功后跳轉(zhuǎn)到首頁時(shí)的鏈接使用http,這個(gè)可能需要開發(fā)代碼里面控制。
上面配置中使用了proxy_set_header X-Forwarded-Proto $scheme,在jsp頁面使用request.getScheme()得到的是https 。如果不把請(qǐng)求的$scheme協(xié)議設(shè)置在header里,后端jsp頁面會(huì)一直認(rèn)為是http,將導(dǎo)致響應(yīng)異常。
ssl配置塊還有個(gè)與不加密的80端口類似的location /,它的作用是當(dāng)用戶直接通過https訪問首頁時(shí),自動(dòng)跳轉(zhuǎn)到不加密端口,你可以去掉它允許用戶這樣做。
3. 實(shí)現(xiàn)雙向ssl認(rèn)證
上面的兩種配置都是去認(rèn)證被訪問的站點(diǎn)域名是否真實(shí)可信,并對(duì)傳輸過程加密,但服務(wù)器端并沒有認(rèn)證客戶端是否可信。(實(shí)際上除非特別重要的場(chǎng)景,也沒必要去認(rèn)證訪問者,除非像銀行U盾這樣的情況)
要實(shí)現(xiàn)雙向認(rèn)證HTTPS,nginx服務(wù)器上必須導(dǎo)入CA證書(根證書/中間級(jí)證書),因?yàn)楝F(xiàn)在是由服務(wù)器端通過CA去驗(yàn)證客戶端的信息。還有必須在申請(qǐng)服務(wù)器證書的同時(shí),用同樣的方法生成客戶證書。取得客戶證書后,還要將它轉(zhuǎn)換成瀏覽器識(shí)別的格式(大部分瀏覽器都認(rèn)識(shí)PKCS12格式):
然后把這個(gè)client.p12發(fā)給你相信的人,讓它導(dǎo)入到瀏覽器中,訪問站點(diǎn)建立連接的時(shí)候nginx會(huì)要求客戶端把這個(gè)證書發(fā)給自己驗(yàn)證,如果沒有這個(gè)證書就拒絕訪問。
同時(shí)別忘了在 nginx.conf 里配置信任的CA:(如果是二級(jí)CA,請(qǐng)把根CA放在后面,形成CA證書鏈)
拓展:使用geo模塊
nginx默認(rèn)安裝了一個(gè)ngx_http_geo_module,這個(gè)geo模塊可以根據(jù)客戶端IP來創(chuàng)建變量的值,用在如來自172.29.73.0/24段的IP訪問login時(shí)使用雙向認(rèn)證,其它段使用一般的單向認(rèn)證。
語法?geo [$address] $variable { … },位于http段,默認(rèn)地址是$reoute_addr,假設(shè)?conf/geo.conf?內(nèi)容:
需要配置另外一個(gè)虛擬主機(jī)server{ssl 445},里面使用上面雙向認(rèn)證的寫法,然后在80或443里使用變量$duplexing_user去判斷,如果為1就rewrite到445,否則rewrite到443。具體用法可以參考nginx geo使用方法。
參考
Nginx部署部分https與部分http
Linux+Nginx/Apache/Tomcat新增SSL證書,開啟https訪問教程
SSL & SPDY 已全面部署
SSL證書與Https應(yīng)用部署小結(jié)
ngx_http_ssl_module docs
Optimizing HTTPS on Nginx
http://zhangge.net/4861.html
http://blog.chinaunix.net/uid-192074-id-3135733.html
轉(zhuǎn)載于:https://blog.51cto.com/qiangsh/1867780
總結(jié)
以上是生活随笔為你收集整理的nginx配置ssl加密(单双向认证、部分https)的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 最近的特别问题(1)
- 下一篇: cometD离线消息