本文介紹了在Debian和Ubuntu系統(tǒng)平臺上實施完美前向保密(Perfect Forward Secrecy)以及NGINX網(wǎng)站服務器的過程。如果是其他GNU/Linux系統(tǒng),整個過程稍有變動。
簡而言之,完美前向保密可以確保“即便一個信息受危及,也不會拖累其他信息受危及;并確保沒有一個秘密值會導致多個消息受危及。”想了解更多信息,請參閱維基百科上的相關(guān)解釋:http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy。
當openSSL中的Heartbleed安全漏洞于2014年年初公之于眾時,這個事實顯得越來越清楚:對于在很大程度上采用SSL/TLS的任何系統(tǒng)而言,完美前向保密必不可少。
萬一你希望將自己的結(jié)果與我的結(jié)果進行比較,可以在https://www.ssllabs.com/ssltest/analyze.html?d=indietorrent.org處測試我的參照實施方法,SSL證書鏈和發(fā)送的NGINX報頭可以在https://indietorrent.org處查看。
閑話少說,不妨配置NGINX來實施完美前向保密。
先不妨進入到NGINX的配置目錄:
cd /etc/nginx/
我們需要生成安全性足夠強的Diffie-Hellman參數(shù)。一些人認為,4096比特過長了,會給系統(tǒng)的處理器帶來不必要的負擔;但是就現(xiàn)在的計算能力而言,這似乎值得一試。想了解更多信息,請參閱下面的“參考資料”部分。
openssl dhparam -out dh4096.pem 4096
要是有這個配置文件很方便,該文件是專門針對手頭的任務,在include文件中被劃分開來;這樣一來,更容易跨數(shù)量眾多的系統(tǒng)來實施完美前向保密。
vi /etc/nginx/perfect-forward-secrecy.conf
將下列內(nèi)容粘貼到上述文件中:
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !MEDIUM";
ssl_dhparam dh4096.pem;
修改NGINX配置,以便加入上述文件,為此只要在http {}代碼段的末尾,將下面這一行插入到NGINX的主配置文件(默認情況下主配置文件是/etc/nginx/nginx.conf):
#See:https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
#This MUST come AFTER the lines that includes …/sites-enabled/*, otherwise SSLv3 support may be re-enabled accidentally.
include perfect-forward-secrecy.conf;
重啟NGINX,讓變更內(nèi)容生效:
service nginx restart
要是https://www.ssllabs.com/ssltest/analyze.html處的測試顯示紅色的Session resumption (caching) No (IDs assigned but not accepted),并且服務器實施了服務器名字指示(SNI),那就添加下列內(nèi)容到頂層的http {}代碼段(即添加到nginx.conf,就在我們之前所添加內(nèi)容的下面):
# See: http://forum.nginx.org/read.php?2,152294,152401#msg-152401
ssl_session_cache shared:SSL:10m;
同樣,重啟NGINX,讓變更內(nèi)容生效:
service nginx restart
上述測試應該不再報告這個問題了(盡管這個問題并不降低總體測試分數(shù))。
更深入一步:實施持續(xù)時間長的HTTP嚴格傳輸安全(HSTS)協(xié)議
這部分很容易實現(xiàn),完全值得一試,前提是:
1.針對該報頭所設置的任何主機,你想要強行要求使用SSL訪問所有資源(也就是相關(guān)網(wǎng)站上的每個網(wǎng)頁)。
2.你可以忍受不能夠接受和忽視針對該報頭所設置的任何主機而請求的任何資源的SSL提醒,比如“Domain Name Mismatch”等。HSTS的性質(zhì)恰恰在于,與SSL證書有關(guān)的警告和錯誤條件無法被覆蓋。
我上網(wǎng)搜索了關(guān)于設置該報頭會不會可能給不支持報頭的瀏覽器帶來不必要的影響方面的信息,結(jié)果發(fā)現(xiàn)信息寥。但我能夠通過在瀏覽器(比如IE 6)中測試這個實施方法來消除我擔心的問題,沒有實施HSTS的瀏覽器完全忽視報頭。太棒了!
只要將下面幾行添加到/etc/nginx/perfect-forward-secrecy.conf的末尾,保存變更內(nèi)容:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# This will prevent certain click-jacking attacks, but will prevent
# other sites from framing your site, so delete or modify as necessary!
add_header X-Frame-Options SAMEORIGIN;
重新加載(而不是重啟)將足以迫使NGINX采用這些特別的變更:
service nginx reload
可以證實 HSTS按預期的方式運行,只要在https://www.ssllabs.com/ssltest/analyze.html處證實這個實施方法。如果HSTS已正確實施,你應該會在分數(shù)正下方看到一個綠色框,顯示“This server supports HTTP Strict Transport Security with long duration. Grade set to A+.”意為“該服務器支持持續(xù)時間長的HTTP嚴格傳輸安全協(xié)議。分數(shù)被定為A+。”
祝賀你!
現(xiàn)在,你擁有了互聯(lián)網(wǎng)上最安全的SSL/TLS實施方法之一。