“干貨”來了！你能借鑒的高校安全證書配置

文/張文正 張寧

“干貨”來了！你能借鑒的高校安全證書配置

文/張文正 張寧

隨著蘋果和騰訊微信小程序強制要求HTTPS安全通信，以及免費證書LetsEncrypt的出現，安全證書（下文簡稱證書）的部署已成為必選項，其部署成本也大為降低。正確部署了證書后，能大幅減少網絡嗅探帶來的安全問題和提高用戶隱私的保護程度。但如果證書部署不正確，其本應具有的安全性會大打折扣，甚至形同虛設。下面就在高校中如何配置安全證書嘗試做一個“最佳實踐”的探討（不探討加密算法等原理）。

高校中的重點保護對象

在高校里，一般需要給這些服務配置安全證書：統一身份認證amp;單點登錄服務、郵件服務、SSL-VPN、部分安全性要求較高的Web應用（如財務系統、科研系統等）、一些需要在手機APP內或微信小程序內調用數據的Web應用等，若有必要的話，也可以考慮給HAProxy（負載均衡前端）、WWW門戶、FTP等服務配置證書。

目前高校統一身份認證amp;單點登錄服務常用的架構是CAS/Shibboleth+LDAP，部分高校還有基于oAuth的認證授權為一體的服務。其中，CAS/Shibboleth/oAuth都走的是HTTP協議，傳輸的是用戶名密碼等高度隱私數據，被第三方系統調用頻率很高。所以應將其作為第一個優先部署證書的服務。后端的LDAP認證系統一般會部署在內網，但若要防范內網攻擊源，也需要對其部署證書。

郵件服務的使用頻率非常高，也容易受到攻擊。郵件服務一般會同時開放Web、IMAP、POP3、SMTP等訪問協議，需要同時在這些服務上配置證書。

值得注意的是：域名系統安全擴展（DNSSEC）的證書體系雖然和本文中的基于X.509協議的證書體系有些不同，但在配置時也可以作為參考。

另外，從信息安全等級保護工作角度來看，可能對于等保定級為2級以上的業務系統最好都需要配置安全證書。

證書服務商的選用

值得推薦的是LetsEncrypt免費證書。LetsEncrypt的贊助商是谷歌、Facebook、Mozilla基金會、Cisco、Akamai（CDN服務商）等巨頭，所以其服務的長期穩定性也是可以保障的。LetsEncrypt提供了Apache/Nginx等服務器端證書自動生成工具，非常方便高效，可配合cron工具自動續期證書。對于SMTP/IMAP/LDAP等服務的配置也可手動完成。但LetsEncrypt無法為個人簽發數字證書，若有需要對郵件、電子印章進行證書簽名的使用場景，則不能選用它。此外，目前由于絕大部分購買的SSL-VPN是硬件式設備，若需要將LetsEncrypt證書應用到其上，需要咨詢廠家是否支持LetsEncrypt證書的自動續期，否則，維護起來比較麻煩。

另外，由于市場占有率排名第一的Chrome瀏覽器逐漸不再信任賽門鐵克及其旗下的SSL證書，若要選購商業證書，需要確認服務商不在黑名單中。

證書配置過程中的注意事項

生成可靠的私鑰

一般選用加密長度為2048的RSA算法生成私鑰，1024位被破解的風險較大。一旦私鑰被破解，證書體系的安全性全部喪失。若在向證書服務提供商申請證書的過程中允許由自己來生成私鑰，在執行相關Open SSL命令時，盡可能通過不停隨機敲擊鍵盤來增加隨機熵值。

選用安全的證書協議

有五種協議SSL v2、SSL v3、TLS v1.0、TLS v1.1和TLS v1.2（SSL v1從未公開發行），其中TLS v1.1和TLS v1.2目前還未發現有安全問題。大家習慣上把安全證書稱為SSL證書，但恰恰SSL v2和SSL v3這兩種協議都是不安全的，嚴禁使用。TLS v1.0也有些小問題，但為了兼顧一些老式的通信對象，可以使用。在默認配置中，也應不啟用TLS v1.0，當發現不兼容問題后，若第三方應用無法更改，可再啟用TLS v1.0。

使用完整的證書鏈

證書鏈可簡單理解為操作系統或瀏覽器內安裝的全球根證書、終端用戶證書以及這兩個證書中間的一級或多級證書服務提供商的證書之間形成一個環環相扣的信任鏈，如果中間缺了某一環，則證書鏈不完整，也就不能確保證書安全。實際配置過程中，管理員有時候會直接把從證書服務提供商處下載的服務器證書文件配置到Apache等配置文件中，忘記將證書提供商的中間證書也要放在證書文件里，就會導致證書鏈不完整的問題。一般來說，直接把服務器證書和提供商的中間證書合并在一個文件中即可（都是文本文件）。

配置恰當的加密組合

加密組合是指證書安全體系中的協議、密鑰交換算法、AES加密算法及其分組加密模式、摘要哈希算法的組合。需要兼顧安全性、通信對象的強制性和兼容性、性能等因素，一般將安全性高的加密組合放在前面，大部分通信對象會使用匹配到的第一項組合，忽略其他組合。

保障Open SSL的安全更新

應設置系統自動安裝安全更新，特別是OpenSSL及其相關庫（如libssl等）的安全更新。Open SSL的安全漏洞往往會導致證書的安全性變得極為脆弱。

Web應用中常用的證書相關問題和配置

由于大多數軟件基礎設施和業務系統都是Web應用，所以對此做側重探討。

1.HTTPS Web應用中引用了非HTTPS的外部服務器鏈接。常見情況是引用了外部的HTTP鏈接的JS/CSS，此時Chrome瀏覽器證書標識小鎖圖標上就會顯示黃色三角形，如下圖：

此時，應優先改為本地引用，或者直接引用無安全問題的HTTPS外部鏈接。

2.安全Cookie配置。開發人員一般習慣于不加密直接讀寫Cookie，尤其是當存儲了HTTP Session數據的Cookie被不法者拿到后會用于中間人攻擊。我們需要在Web服務器內啟用安全Cookie，這樣，Web服務器就會拒絕不是由瀏覽器發出的Cookie。如Apache的配置是：Header edit Set-Cookie^(.＊)$ $1;HttpOnly;Secure

3.啟用HTTP嚴格傳輸安全（HSTS）配置。當Web服務器中的證書配置有誤時，HSTS仍能指示瀏覽器保障安全通信，瀏覽器也不會提醒用戶忽略警告繼續訪問（最常發生于證書過期時）。如Apache的：Header always set Strict-Transport-Security quot;maxage=15768000quot;

4.對非敏感性資源啟用客戶端緩存。WWW門戶訪問量一般很大，若要對其配置證書，需要啟用圖片等非敏感性資源的客戶端緩存以提升性能，一般需要在Web服務器內做相關設置，如Apache的：

lt;FilesMatch quot;.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$quot;gt;

Header set Cache-Control quot; publicquot;

lt;/FilesMatchgt;

對于配置了自簽名的證書的應用則不可啟用HSTS，否則用戶無法忽略安全警告和繼續使用服務。

高校環境中常見的兼容性問題

1.Windows XP中IE8及以下版本瀏覽器不支持新式的加密算法，若必須要支持，需要啟用RC4加密算法，Web服務器端需在加密組合的配置中添加RSA-WITH-RC4-128-SHA和RC4+SHA。顯然，這會降低證書的安全性，所以優先做法是說服用戶升級操作系統和瀏覽器。

2.JRE/JDK 6中的Diffie-Hellman加密算法的加密長度最多只能支持1024位，導致無法和2048位的證書通信，從而出錯。這類問題最常發生在基于JDK6開發的應用在和單點登錄系統對接時，而升級JDK又造成應用無法正常使用。這種現象在部分高校應用系統中比較常見。此時，我們只能動“小手術”，將JDK 6的Security Provider改成BouncyCastleProvider（可從http://repo1.maven.org/maven2/org/bouncycastle/中下載bcprov-ext-jdk16-1.46.jar 和bcprovjdk16-1.46-javadoc.jar并作適當配置）。

相關工具

運用以下幾個工具能減少出錯機率，讓配置工作事半功倍。

1.SSL Labs證書安全性在線檢測和診斷工具 https://www.ssllabs.com/ssltest/ ：一般B級及以上才可視為具有足夠的安全性。建議高校同行都使用該工具檢測一遍學校的證書的安全性。在診斷結果的“Handshake Simulation”小節中可看出通信對象的兼容性，可幫助預判兼容性問題，在移動互聯網時代，特別要注意移動設備的兼容性。也可以利用該工具查看國內大型網站和美國高校的證書配置，可學習借鑒其如何處理安全性和兼容性的做法。

2.服務器證書配置文件生成工具https://mozilla.github.io/server-side-tls/ssl-config-generator/ ：可生成Apache/Nginx等服務的配置。優先考慮使用Modern類型的配置（其中，Apache需要2.4.＊版本才支持Modern類型）。

3.在線完整證書鏈生成工具 https://certificatechain.io/

（責編：王左利）

為上海外國語大學）