文/張文正 張寧

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

文/張文正 張寧

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

高校中的重點(diǎn)保護(hù)對(duì)象

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

目前高校統(tǒng)一身份認(rèn)證amp;單點(diǎn)登錄服務(wù)常用的架構(gòu)是CAS/Shibboleth+LDAP，部分高校還有基于oAuth的認(rèn)證授權(quán)為一體的服務(wù)。其中，CAS/Shibboleth/oAuth都走的是HTTP協(xié)議，傳輸?shù)氖怯脩裘艽a等高度隱私數(shù)據(jù)，被第三方系統(tǒng)調(diào)用頻率很高。所以應(yīng)將其作為第一個(gè)優(yōu)先部署證書的服務(wù)。后端的LDAP認(rèn)證系統(tǒng)一般會(huì)部署在內(nèi)網(wǎng)，但若要防范內(nèi)網(wǎng)攻擊源，也需要對(duì)其部署證書。

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

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

另外，從信息安全等級(jí)保護(hù)工作角度來看，可能對(duì)于等保定級(jí)為2級(jí)以上的業(yè)務(wù)系統(tǒng)最好都需要配置安全證書。

證書服務(wù)商的選用

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

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

證書配置過程中的注意事項(xiàng)

生成可靠的私鑰

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

選用安全的證書協(xié)議

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

使用完整的證書鏈

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

配置恰當(dāng)?shù)募用芙M合

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

保障Open SSL的安全更新

應(yīng)設(shè)置系統(tǒng)自動(dòng)安裝安全更新，特別是OpenSSL及其相關(guān)庫（如libssl等）的安全更新。Open SSL的安全漏洞往往會(huì)導(dǎo)致證書的安全性變得極為脆弱。

Web應(yīng)用中常用的證書相關(guān)問題和配置

由于大多數(shù)軟件基礎(chǔ)設(shè)施和業(yè)務(wù)系統(tǒng)都是Web應(yīng)用，所以對(duì)此做側(cè)重探討。

1.HTTPS Web應(yīng)用中引用了非HTTPS的外部服務(wù)器鏈接。常見情況是引用了外部的HTTP鏈接的JS/CSS，此時(shí)Chrome瀏覽器證書標(biāo)識(shí)小鎖圖標(biāo)上就會(huì)顯示黃色三角形，如下圖：

此時(shí)，應(yīng)優(yōu)先改為本地引用，或者直接引用無安全問題的HTTPS外部鏈接。

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

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

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

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

Header set Cache-Control quot; publicquot;

lt;/FilesMatchgt;

對(duì)于配置了自簽名的證書的應(yīng)用則不可啟用HSTS，否則用戶無法忽略安全警告和繼續(xù)使用服務(wù)。

高校環(huán)境中常見的兼容性問題

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

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

相關(guān)工具

運(yùn)用以下幾個(gè)工具能減少出錯(cuò)機(jī)率，讓配置工作事半功倍。

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

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

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

（責(zé)編：王左利）

為上海外國(guó)語大學(xué)）