SSL/TLS通訊保密協議保安指引

引言

SSL/TLS_[1] 通訊保密協議在資訊系統及互聯網的應用非常廣泛，它確保了應用通訊的保密性。其中最常見的是用於網站與瀏覽器之間的通訊加密HTTPS_[2]。典型的例子是防止電子商貿中的交通被中間竊聽或修改交易數據。不過，部份SSL/TLS協議的版本存在漏洞或弱點，如果設置不當，可能增加資訊保安的風險。

指示﹕使用「檢查--執行--驗證」的方法去提高網站於使用SSL/TLS上的保安。

本指引主要分為兩個部份，第一部份是「檢查」，此部份介紹如何使用免費工具「檢查」網站的SSL/TLS通訊保密協議及其配置。你將於完成檢查後獲知測試網站的SSL/TLS保安評級及取得檢查報告。完成「檢查」後，你可把檢查報告交給技術人員跟進，以執行「修正」方案。

第二部份是「修正」，此部份介紹一些SSL/TLS通訊保密協議的使用安全及配置建議，技術人員可參考此部份來執行「修正」方案，以改進測試網站的SSL/TLS保安評級。完成執行「修正」方案後，你需要進行「驗證」，重複第一部份的相同檢查去「驗證」SSL/TLS保安評級是否有所改進。
 


注﹕本文在分析SSL/TLS實施現況時，引用SSL Labs_[3] 和其項目SSL Pulse_[4] 的資料。
 

SSL/TLS協議的保安風險

SSL/TLS協議已經推出一段時間，在1996年發佈的SSL3.0存在不少已知的漏洞，例如著名的POODLE 、 Heartbleed和 FREAK_[7]。另外，配置不當也可能引發潛在的保安風險，包括資料洩漏和網絡攻擊等。為了減低這些風險，我們必須使用一些安全的SSL/TLS通訊保密協議及跟據最佳實施來確保其配置正確。

注意﹕本保安指引對SSL/TLS通訊保密協議作出的建議是建基於HTTP的應用。

本中心根據SSL Pulse_[6] 項目所收集的數據(由項目2012年4月首次發布日至2015年5月7日)，分析了SSL/TLS通訊保密協議在使用上的保安問題。當中發現有超過四分之三參與此項目的網站在 QUALYS SSL Server Test 中被評為「保安不足」 (B或以下)。 同時，只有約四分之一的網站能於此測試中獲得「A」級成績。這顯示大部份參與測試的網站在配置SSL/TLS通訊保密協議上仍然有頗大的進步空間，情況值得關注。
 

第一部份﹕如何檢查SSL/TLS通訊保密協議及配置

人手檢查SSL/TLS通訊保密協議的配置是一個較傳統的檢測方法，檢測者需要有相關技術知識。由於缺乏相關知識或技術，這往往令人卻步。

今天，有不少提供網上檢查網站的SSL/TLS協議及配置的測試服務網站，祇需簡單的使用步驟﹕輸入想測試的網站的網址，點擊同意使用條款，按下「開始」按鈕，自動檢查便會進行，然後，你便會得到測試報告。你不需要是一個專家，你可以進行自動檢查，然後把測試報告交給技術人員跟進，再在以後再執行自動檢查，驗證是否有所改進。
 

以下為一些常用的SSL/TLS配置檢查工具_#﹕

網站伺服器檢查工具﹕

• COMODO SSL Analyzer
  https://sslanalyzer.comodoca.com/
• QUALYS SSL Server Test
  https://www.ssllabs.com/ssltest/
• Symantec SSL Certificate Installation Checker
  https://cryptoreport.websecurity.symantec.com/checker/

電郵伺服器檢查工具﹕

• SSL-Tools (Test SSL/TLS configuration of email server)
  https://ssl-tools.net/mailservers
• Check TLS (safe email testing tool and service)
  http://www.checktls.com/

以下會詳細介紹QUALYS SSL Server Test，它是HTTP市場上認受性較高的SSL/TLS測試工具。
https://www.ssllabs.com/ssltest/

此工具除了可令你了解你的網站於SSL/TLS配置上的評級外，更提供詳細報告及指引，讓你可自行修補問題，從而提升網站的安全評級。

步驟1. 於Domain name輸入網址，若不希望公開測試結果，請選擇下方的空格。最後按Submit便可進行測試。


步驟2. 測試進行中，請耐心等候。


步驟3. 測試結果報告，有問題的配置會以不同顏色文件顯示，並可查看詳細解釋以修補配置。


如何成為「A」級網站?
你只需要參照本文的第二部份去配置網頁伺服器，成功後應該就能奪「A」級成績。
注﹕假設基本的SSL/TLS設定已正確地配置。
 

第二部份﹕SSL/TLS通訊保密協議的使用安全及配置建議
 

一﹕基本防護

一些基本防護很容易被忽略，但它們對安全使用SSL/TLS通訊保密協議是非常重要的。

-    定期更新系統
定期更新系統能有效修復一些已知的SSL/TLS協議漏洞。例如﹕OpenSSL的Heartbleed漏洞_[8] 和SSL/TLS不安全的重新交涉漏洞 (insecure renegotiation)_[9]。

-    使用較新版本的軟件及協議
一般來說，較新的軟件版本能支援以較強雜湊算法所簽發的數碼證書_[10],、較安全的TLS協議和支援更安全的加密套件(Cipher Suites)。因此，無論是操作系統、網絡設備或瀏覽器，擁有人/管理員應盡量使用較新的版本來支援更安全的保安配置。

二﹕使用安全的數碼證書
由於電腦的運算能力越來越強，記憶體越來越多，要破解舊的雜湊算法亦會變得更容易。為對抗這上升的風險，一些核證機關(CA) 已經以更安全的2048-bit(密匙長度) 證書和SHA2 /SHA-256作為簽發數碼證書的預設雜湊算法，取代現在的1024-bit(密匙長度)證書和SHA1雜湊算法。

-    使用新加密方式SHA2 /SHA-256簽發的數碼證書
根據SSL Pulse的數據，約一半使用SSL/TLS的網站仍使用SHA1簽發的數碼證書_[6]。可是，由於保安理由，瀏覽器更新版本將不再支援較舊的SHA1雜湊算法簽發的數碼證書。若網站仍使用SHA1簽發的數碼證書，新版本瀏覽器會把其數碼證書視為無效，並顯示為不安全網站_[11]。因此，本中心建議網站擁有人應盡快更新用2048-bit(密匙長度) 證書和較強的雜湊算法SHA2 /SHA-256簽發的數碼證書，以減低對使用者的影響。

-    確保使用完整的數碼證書鏈 (Certificate Chain)
除了擁有一張安全的數碼證書外，完整的數碼證書鏈也很重要。不正確配置數碼證書鏈除了可能令數碼證書不能正常運作外，更可能被使用者懷疑網站的真偽。在一般的情況，網站擁有人/管理者只需要把根證書或/和中繼證書一併匯入伺服器，並加以設定，便能配置正確的數碼證書鏈。詳情可參考核證機關(CA)的網站_[12]。

三﹕配置遠期保密 (Forward Secrecy)
遠期保密設置可加強通訊內容的保密性，它確保每次加密使用的密鑰都是獨立的及只是短暫性有效，就算日後某密鑰被破解或被盜取，攻擊者始終無法解讀過去已加密的通訊內容_[13]。

跟據SSL Pulse的報告，只有約五分之一的網站已配置遠期保密安全設定，並支援大部份的瀏覽器_[6]。可見還有大量網站並沒有設置遠期保密，這些網站仍然存有資訊保安的風險。為逹至遠期保密安全，網站擁有人/管理者可設定以下配置。

-    使用安全的SSL/TLS通訊保密協議版本
一些較舊的SSL/TLS通訊保密協議版本可能存在資訊保安的風險。 本中心早前的博錄 [/my_url/blog/15012902]亦提及，SSL3.0 存在 POODLE 保安漏洞，已變得不安全。現時TLSV1.2 是最安全的SSL/TLS協議。由於TLS1.0仍屬主流的SSL/TLS協議，本中心建議網站擁有人/管理人使用TLS 1.2，並同時向後兼容TLS1.1 和TLS1.0。基於保安理由，請停用支援SSL3.0 及以下版本。另外，伺服器端亦需要以此次序與用戶交涉﹕「TLS1.2 > TLS1.1 > TLS1.0」。若能支援較新的版本，便應強制使用較新的版本_[14]。有關SSL/TLS協議的情況，請參考下表_[14]。
 

-    使用安全的加密套件 (Cipher Suites)
較舊的加密套件，使用的算法隨著運算能力的增強，已不夠安全，可能增加資料外洩的風險。2013年，有研究發現RC4加密套件已經不夠安全_[15],[16]。從SSL Pulse的數據顯示，約近一半的網站仍然使用RC4加密套件_[6]。因此，本中心建議網站管理員應於網頁伺服器使用較安全算法的加密套件作優先 (例如﹕ECDHE、AES256)，隨後是可能有安全風險但仍廣泛被使用的加密套件 (例如﹕SHA1)，但必須停用一些已知高風險的加密套件(例如﹕MD5、RC4)_[17]。
 

注﹕若系統能支援較新的版本，便應強制使用較新的版本 例如: 先使用AES256，若不能成功才使用AES128。

以下為配置加密套件和優先次序的例子，此配置平衡保密性 (confidentiality) 及可用性 (Availability)，以兼容大部份用戶﹕

注意﹕加密套件 (Cipher Suites) 設定的優先次序由高到低

注﹕ 除了伺服器端需要進行設定外，用戶端 (瀏覽器和操作系統) 也需要同時配合才能確保資料的保密性。一般較新的瀏覽器及操作系統均支援遠期保密所需的加密套件_[18]。
 

四﹕其他SSL/TLS安全設定的建議
-    在伺服器端停用SSL/TLS Compression 設定
事實上，只有極少數用戶端支援SSL/TLS Compression 設定。可是，使用SSL/TLS Compression設定可能受到CRIME攻擊_[19]，導致洩露敏感資料。因此，若非必要的情況下，本中心建議在伺服器端停用SSL/TLS Compression 設定。

-    配置HTTP Strict Transport Security (HSTS)
HSTS_[20] 是一個伺服器端設定 (RFC6797)，可強制用戶端以SSL/TLS加密連接，確保通訊保密性。
例如，若 www.hkcert.org 網頁伺服器已設定HSTS，當使用者於瀏覽器 (用戶端) 輸入 http://www.hkcert.org，伺服器會自動把請求轉向 https://www.hkcert.org。這項設定也需要用戶端的支援，否則用戶端將會顯示錯誤信息_[21]。較新的瀏覽器均已支援HSTS。

隨着電子商貿的發展，資料保密性越來越被大眾及企業重視，本中心相信HTTPS 安全連接將變得非常流行，HSTS 配置亦變得更重要。

-    配置HTTP Public Key Pinning
HTTP Public key pinning (HPKP) _[22] 是一個伺服器端設定。用戶端於傳輸數據前先檢查特定數碼證書的公鑰是否被改動，令使用者能辨別出數碼證書的真偽 _[23]。瀏覽器在第一次訪問配置了HPKP網站，瀏覽器便會暫存了網站的公鑰。假若其後有攻擊者進行中間人攻擊，偽裝HTTPS網站，以圖截聽加密的通訊，瀏覽器便會識別暫存的公鑰與偽裝網站的公鑰不相同，瀏覽器便會阻止與偽裝網站的連接。因此，HPKP的配置可以提供點對點的加密保護，並且可以避免因攻擊者透過其他核證機關(CA)申請相同域名的數碼證書，令用戶進入偽冒網站。

由於HPKP仍未非常普及，這些配置可能與較舊的瀏覽器存在兼容性問題_[24]。故本中心建議使用者根據需要決定是否配置HPKP。同時，使用者亦要小心配置HPKP，必須考慮不同情況下的應對方案，例如﹕更新/撤銷數碼證書和遺失私密金鑰(Private Key)時如何應對。配置詳情請參考配置伺服器的文件。
 

註：HKCERT建議伺服器管理人在實行任何配置 (包括HSTS和/或HPKP) 前，應建立一個周全的計劃，並考慮配置所帶來的影響。

參考資料

1. TLS 是新一代的SSL通訊保密協議，它提供更佳的保密性。
2. 於萬維網(WWW)中所使用的SSL/TLS，普遍稱為HTTPS。於電郵中所使用的SSL/TLS，普遍稱為POP3S、SMTPS及IMAPS。
3. SSL Labs 是Qualys的非商業研究，目的是為了讓大眾瞭解及改進SSL，它亦包含不少有關SSL的文件及工具。_[5]
4. SSL Pulse 是使用SSL Labs評估技術的一個項目，由2012年4月25日首次發布，並不斷更新。它監測熱門網站實行SSL的情況，目的是為了促使網站擁有人/管理員可以持續改善SSL的實施。_[6]
5. https://www.ssllabs.com/
6. https://www.trustworthyinternet.org/ssl-pulse/
7. https://en.wikipedia.org/wiki/Transport_Layer_Security
8. http://heartbleed.com/
9. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
10. http://www.hongkongpost.gov.hk/support/faq/index_c.html#P2
11. http://www.symantec.com/page.jsp?id=sha2-transition
12. https://hongkongpost.gov.hk/product/download/root/index.html
13. http://en.wikipedia.org/wiki/Forward_secrecy
14. https://www.rfc-editor.org/rfc/rfc7525.txt
15. https://tools.ietf.org/html/rfc7465
16. http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2868725-recommendation-to-disable-rc4.aspx
17. http://www.cisco.com/c/en/us/about/security-center/next-generation-cryptography.html
18. https://www.ssllabs.com/ssltest/clients.html
19. https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls
20. https://www.owasp.org/index.php/HTTP_Strict_Transport_Security
21. https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
22. https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
23. https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning
24. https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
25. https://timtaubert.de/blog/2014/10/http-public-key-pinning-explained/
26. https://raymii.org/s/articles/HTTP_Public_Key_Pinning_Extension_HPKP.html

^#免責聲明：
HKCERT 不會推介特定供應商的產品或服務。這個列表中的產品或服務，並不意味是 HKCERT 的推介。工具列表中沒有質量評級。這個列表內的工具屬程式開發者或產品/服務供應商所有，他們能夠隨時更改程式。HKCERT 沒有查實當中的程式的完整性，如在使用上遇到任何問題，請直接連絡程式開發者或產品/服務供應商。