胡仁林 ,張立武

1(中國科學(xué)院大學(xué),北京 100049)2(中國科學(xué)院 軟件研究所,北京 100190)

Web網(wǎng)站SSL/TLS協(xié)議配置安全研究①

胡仁林1,2,張立武2

1(中國科學(xué)院大學(xué),北京 100049)2(中國科學(xué)院 軟件研究所,北京 100190)

SSL/TLS協(xié)議是目前通信安全和身份認(rèn)證方面應(yīng)用最為廣泛的安全協(xié)議之一,對于保障信息系統(tǒng)的安全有著十分重要的作用.然而,由于SSL/TLS協(xié)議的復(fù)雜性,使得Web網(wǎng)站在實(shí)現(xiàn)和部署SSL/TLS協(xié)議時,很容易出現(xiàn)代碼實(shí)現(xiàn)漏洞、部署配置缺陷和證書密鑰管理問題等安全缺陷.這類安全問題在Web網(wǎng)站中經(jīng)常發(fā)生,也造成了許多安全事件,影響了大批網(wǎng)站.因此,本文首先針對Web網(wǎng)站中安全檢測與分析存在工具匱乏、檢測內(nèi)容單一、欠缺詳細(xì)分析與建議等問題,設(shè)計并實(shí)現(xiàn)了Web網(wǎng)站SSL/TLS協(xié)議部署配置安全漏洞掃描分析系統(tǒng),本系統(tǒng)主要從SSL/TLS協(xié)議基礎(chǔ)配置、密碼套件支持以及主流攻擊測試三方面進(jìn)行掃描分析; 之后使用該檢測系統(tǒng)對Alexa排名前100萬網(wǎng)站進(jìn)行掃描,并做了詳細(xì)的統(tǒng)計與分析,發(fā)現(xiàn)了不安全密碼套件3DES普遍被支持、關(guān)鍵擴(kuò)展OCSP Stapling支持率不足25%、仍然有不少網(wǎng)站存在HeartBleed攻擊等嚴(yán)重問題; 最后,針對掃描結(jié)果中出現(xiàn)的主要問題給出了相應(yīng)的解決方案或建議.

Web 網(wǎng)站; SSL/TLS 協(xié)議; 安全漏洞掃描; 基礎(chǔ)配置; 密碼套件

1 引言

SSL/TLS協(xié)議[1]作為網(wǎng)絡(luò)信息系統(tǒng)中應(yīng)用最為廣泛的協(xié)議之一,對于保障信息系統(tǒng)的安全有著十分重要的作用.HTTPS是超文本傳輸協(xié)議HTTP和SSL/TLS協(xié)議的組合,它提供了Web網(wǎng)站的安全通信需求.目前各大瀏覽器產(chǎn)商、搜索引擎公司以及相關(guān)研究組織的一系列項(xiàng)目與決策都推動著HTTPS的快速發(fā)展.據(jù)Chrome和Firefox所給出的數(shù)據(jù)表明[2,3],現(xiàn)在全世界范圍內(nèi)超過一半的網(wǎng)頁采用了HTTPS.

由于SSL/TLS協(xié)議的復(fù)雜性,使得Web應(yīng)用系統(tǒng)在實(shí)現(xiàn)和部署SSL/TLS協(xié)議時,很容易出現(xiàn)代碼實(shí)現(xiàn)漏洞、部署配置缺陷和證書密鑰管理問題等安全缺陷.例如,2014 年 3 月公布的 HeartBleed 漏洞[4],由于廣泛使用的開源組件OpenSSL存在實(shí)現(xiàn)缺陷,造成了超過50萬臺服務(wù)器受到攻擊,導(dǎo)致服務(wù)器私鑰和用戶會話Cookie及密碼被盜; 2016 年 3 月,公布的 DROWN 漏洞主要利用弱加密算法對RSA進(jìn)行破解,這種類型攻擊很可能使目前至少三分之一的HTTPS服務(wù)器癱瘓;2015年8月,清華大學(xué)鄭曉峰等人[5]公布了一個存在于主要瀏覽器的Web Cookie注入漏洞,攻擊者通過此漏洞可以竊取私密的私人會話數(shù)據(jù),導(dǎo)致Google、Amazon、Apple以及中國銀聯(lián)等網(wǎng)站都受此影響.

針對以上SSL/TLS協(xié)議實(shí)現(xiàn)和部署配置方面的安全缺陷,實(shí)時在線的對Web服務(wù)器進(jìn)行安全檢測,并報告存在的漏洞風(fēng)險,具有十分重要的意義.對Web網(wǎng)站中SSL/TLS協(xié)議實(shí)現(xiàn)與部署配置方面進(jìn)行檢測,一般來說主要分為如下三個部分:HTTPS基礎(chǔ)配置、密碼套件支持以及攻擊測試.這三者之間既相互關(guān)聯(lián),也相互制約,基礎(chǔ)配置和密碼套件存在問題不僅可能導(dǎo)致相應(yīng)的攻擊,也可能導(dǎo)致會話無法成功建立,而類似HeartBleed這類攻擊則是對其所配置的SSL開源組件實(shí)現(xiàn)方面的檢測.

近年來,與SSL/TLS協(xié)議部署配置相關(guān)的安全檢測受到了研究者的廣泛關(guān)注.Qualys SSL Labs[6]是 Ivan Risti?等人于2009年發(fā)起的一個項(xiàng)目,一個在線版全球知名的HTTPS網(wǎng)站檢測工具,它提供服務(wù)器/客戶端安全檢測、SSL Pluse(全球HTTPS網(wǎng)站統(tǒng)計報告)以及相關(guān)API接口調(diào)用; 針對密碼套件方面的分析,Mozilla的開源項(xiàng)目CipherScan[7]可以實(shí)現(xiàn)對目標(biāo)服務(wù)器進(jìn)行密碼套件的全面掃描與分析,同時它也提供簡單的證書驗(yàn)證、擴(kuò)展支持以及密鑰大小的掃描分析服務(wù); TLS-Attacker[8]是由 Juraj Somorovsky 開發(fā)并維護(hù),用于測試評估TLS實(shí)現(xiàn)庫的開源框架,它可以自定義TLS消息序列、任意地動態(tài)修改TLS消息內(nèi)容,以檢測可能存在的問題.

一方面,以上開源項(xiàng)目基本都是針對單個網(wǎng)站進(jìn)行測試,并不適用于大范圍的高效測試; 另外,它們還存在以下不足與缺陷:

SSL Pluse統(tǒng)計數(shù)據(jù)不全面,受限于網(wǎng)站管理人員是否愿意公開其網(wǎng)站配置信息;

SSL Labs對密碼套件掃描不全面,只針對最高的SSL/TLS版本進(jìn)行了測試;

TLS-Attacker本身是針對SSL/TLS開源組件(如OpenSSL、GnuTLS等)進(jìn)行測試與分析,而非實(shí)際HTTPS網(wǎng)站.

綜上所述,目前缺乏一個涵蓋SSL/TLS協(xié)議基礎(chǔ)配置、密碼套件支持以及主流攻擊測試方面的Web網(wǎng)站SSL/TLS協(xié)議部署配置安全檢測分析系統(tǒng).因此本文主要通過設(shè)計開發(fā)一個Web網(wǎng)站安全檢測分析系統(tǒng),對Alexa排名靠前的HTTPS網(wǎng)站進(jìn)行深入的統(tǒng)計調(diào)研分析,發(fā)現(xiàn)并分析存在的主要問題,最后給出相應(yīng)的建議.

2 相關(guān)工作

在 SSL/TLS 客戶端檢測方面,Jeff Hodges 等人[9]創(chuàng)建了 How’s My SSL 網(wǎng)站,它是一個針對 SSL 客戶端安全配置的在線檢測工具,從協(xié)議版本、基本配置擴(kuò)展以及攻擊測試等方面給予了詳盡的測試分析,并且提供了相關(guān)API接口以供本地測試調(diào)用.

著名網(wǎng)絡(luò)安全公司High-Tech Bridge SA在2015年10月推出的一個驗(yàn)證任何基于SSL/TLS協(xié)議服務(wù)器配置的在線檢測評估工具High-Tech Bridge Free SSL Server Test[10],它主要以 NIST guidelines[11]、PCI DSS requirements[12]以及 HIPAA guidance[13]作為網(wǎng)站安全評估準(zhǔn)則,對HTTPS網(wǎng)站的SSL/TLS協(xié)議的部署配置進(jìn)行檢測評估,最后并給出相應(yīng)的安全等級.

SSL/TLS Deployment Best Practices[14]是 Qualys SSL Labs于2012年開始的一個項(xiàng)目,主要針對SSL/TLS協(xié)議在應(yīng)用中部署配置容易導(dǎo)致的常見問題給出了相應(yīng)的最佳部署建議.目的是讓已經(jīng)不堪重負(fù)的系統(tǒng)管理人員盡可能花少量時間就能完成HTTPS安全站點(diǎn)的搭建.

2.1 組織結(jié)構(gòu)

本文的后續(xù)章節(jié)安排如下:第3節(jié)闡述了Web網(wǎng)站SSL/TLS協(xié)議配置安全檢測系統(tǒng)的研究與設(shè)計工作,詳細(xì)描述了關(guān)鍵模塊的實(shí)現(xiàn)細(xì)節(jié); 第4節(jié)結(jié)合我們的檢測系統(tǒng)對實(shí)際Web網(wǎng)站進(jìn)行檢測后的結(jié)果與分析; 第5節(jié)針對掃描中出現(xiàn)的主流問題給出了相應(yīng)的解決方案或建議; 第6節(jié)總結(jié)了本文的工作.

3 Web 網(wǎng)站 SSL/TLS 協(xié)議配置安全檢測系統(tǒng)設(shè)計與實(shí)現(xiàn)

3.1 設(shè)計目標(biāo)

本檢測系統(tǒng)旨在針對SSL/TLS協(xié)議在Web網(wǎng)站中的基礎(chǔ)配置、密碼套件支持以及主流攻擊測試方面進(jìn)行檢測與分析.本系統(tǒng)主要在現(xiàn)有的開源項(xiàng)目上進(jìn)行改進(jìn)與集成,我們認(rèn)為Web網(wǎng)站SSL/TLS協(xié)議安全檢測系統(tǒng)應(yīng)當(dāng)具備以下特性:

(1)檢測要全面詳細(xì).對 Web 網(wǎng)站中 SSL/TLS 協(xié)議的實(shí)現(xiàn)與部署進(jìn)行分析,需要全面深入地檢測SSL/TLS協(xié)議部署配置的各個方面,如各協(xié)議版本下的密碼套件支持情況等.

(2)高效性.由于是對Alexa排名前100萬網(wǎng)站的測試,因此我們需要高效地完成測試與分析.引入多線程、多進(jìn)程思想,并結(jié)合考慮到SSL/TLS協(xié)議中等待時間限制等問題,設(shè)計了適用于SSL/TLS協(xié)議攻擊測試的特定并發(fā)程序.

(3)可擴(kuò)展性.主流攻擊測試方面應(yīng)該具有可擴(kuò)展性,面向接口編程,對于新型攻擊的出現(xiàn),只需要編寫相應(yīng)的攻擊代碼,并引入到主程序中,即可實(shí)現(xiàn)對新型攻擊的測試.

3.2 設(shè)計思想

本檢測系統(tǒng)對Web網(wǎng)站的SSL/TLS協(xié)議部署配置方面進(jìn)行全面檢測與分析.針對SSL/TLS協(xié)議基礎(chǔ)配置方面,我們將使用 SSL Labs 提供的 API接口,對其請求進(jìn)行封裝,并根據(jù)其API接口要求進(jìn)行特定的并發(fā)程序開發(fā); 對于密碼套件支持方面,我們將借助CipherScan掃描工具,將其以構(gòu)件形式封裝到本系統(tǒng)中,并使用相關(guān)命令進(jìn)行調(diào)用; 對于主流攻擊測試方面,我們將使用TLS-Attacker工具,并對其整體架構(gòu)、高效性進(jìn)行重新設(shè)計與實(shí)現(xiàn),使其能夠?qū)?shí)際的Web網(wǎng)站進(jìn)行高效測試.之后,再將上述三個關(guān)鍵模塊整合進(jìn)行本系統(tǒng),進(jìn)行集成開發(fā),獲取的相關(guān)數(shù)據(jù)存儲在MySQL本地數(shù)據(jù)庫或以文件形式存儲; 最后,對數(shù)據(jù)進(jìn)行相應(yīng)的分析,并對外提供報表輸出接口,將分析結(jié)果、解決方案或建議以報表形式呈現(xiàn)出來.

3.3 系統(tǒng)架構(gòu)

本檢測系統(tǒng)邏輯架構(gòu)圖如圖1所示.主要由數(shù)據(jù)收集層、存儲層、數(shù)據(jù)分析層、應(yīng)用層四個相對獨(dú)立的構(gòu)件組成.數(shù)據(jù)收集層主要從SSL/TLS協(xié)議基礎(chǔ)配置、密碼套件支持以及主流攻擊測試三個方面進(jìn)行數(shù)據(jù)收集,分別用到SSL Labs的接口服務(wù)、CipherScan密碼套件掃描工具以及TLS-Attacker攻擊測試工具.數(shù)據(jù)收集層掃描獲取的數(shù)據(jù)一般存儲于MySQL本地數(shù)據(jù)庫或者以文件形式存儲.數(shù)據(jù)分析層主要對對收集來的數(shù)據(jù)從基礎(chǔ)配置、密碼套件支持以及主流攻擊測試三個方面進(jìn)行深入的統(tǒng)計分析.應(yīng)用層主要是根據(jù)統(tǒng)計分析的結(jié)果,輸出分析報表,并對存在的主要問題給出相應(yīng)的解決方案或建議.

圖1 系統(tǒng)邏輯層次圖

數(shù)據(jù)分析層是本系統(tǒng)的核心層,它主要包括SSL/TLS協(xié)議基礎(chǔ)配置分析模塊、密碼套件支持分析模塊、主流攻擊測試分析模塊,如圖2所示.

圖2 安全配置分析檢測內(nèi)容示意圖

SSL/TLS協(xié)議基礎(chǔ)配置分析模塊.基礎(chǔ)配置方面的檢測主要包括:證書驗(yàn)證、協(xié)議版本以及配置擴(kuò)展支持情況.其中證書驗(yàn)證方面又具體包含了證書簽名算法、證書有效期檢驗(yàn)、證書域名匹配、證書私鑰大小以及證書鏈完整性等等; 協(xié)議版本支持方面,要分別測試Web服務(wù)器對SSL2.0、SSL3、TLS1.0、TLS1.1以及TLS1.2的支持情況; 最后再測試Web服務(wù)器對NIST guidelines[11]中所規(guī)定擴(kuò)展的支持情況.

SSL/TLS協(xié)議密碼套件支持分析模塊.通過在各版本SSL/TLS協(xié)議建立情況下,測試其對所有密碼套件的支持情況.具體統(tǒng)計分析其密鑰協(xié)商算法、會話密鑰強(qiáng)度以及完美前向安全套件的支持情況.

SSL/TLS協(xié)議主流攻擊測試分析模塊.本文中主要針對SSL/TLS協(xié)議中目前出現(xiàn)的主流攻擊進(jìn)行了測試與分析,包括:HeartBleed 攻擊、POODLE 攻擊、PaddingOraclce攻擊、InvalidCurve攻擊等.統(tǒng)計分析了各類攻擊的結(jié)果,并給出了相應(yīng)的解決建議.

3.4 SSL/TLS協(xié)議基礎(chǔ)配置檢測模塊

在 1.1 節(jié)中,我們已經(jīng)提到雖然 Qualys SSL Labs提供了比較全面的HTTPS服務(wù)器部署配置檢測,然而其SSL Pluse統(tǒng)計數(shù)據(jù)受限于網(wǎng)站管理人員是否愿意公開其網(wǎng)站部署信息,并且對密碼套件掃描方面并不全面.基于以上原因,我們將利用其公開的API接口,進(jìn)行請求的封裝,獲取Alexa排名前100萬網(wǎng)站的HTTPS部署配置信息.

根據(jù) Qualys SSL Labs 提供的最新 API文檔:SSL Labs API Documentation v1.24.4[15],我們對 SSL Labs接口進(jìn)行了封裝,并使用Retrofit2開源框架簡化了HTTP請求處理,然后使用Gson對返回的數(shù)據(jù)轉(zhuǎn)成Pojo對象,接著使用Hibernate作為數(shù)據(jù)持久層存儲框架,最后將所有解析后的數(shù)據(jù)存儲到MySQL本地數(shù)據(jù)庫,大致示意圖如圖3.

圖3 SSL Labs接口調(diào)用示意圖

另一方面,為了加快數(shù)據(jù)收集工作的進(jìn)行,但是又不能超過API文檔中規(guī)定的最大請求數(shù)量(為了防止濫用API接口,SSL Labs規(guī)定允許同時發(fā)起的最大請求數(shù)量為25),我們設(shè)計了特定的多線程并發(fā)程序,大體思想如下:使用Java線程池,并設(shè)定線程池大小為最大請求數(shù)量25,監(jiān)測已發(fā)起的請求數(shù)量,一旦某個請求返回了響應(yīng)結(jié)果,就執(zhí)行請求隊(duì)列消息中的下一個請求,使得請求數(shù)量一直處于飽和狀態(tài),最大限度地使用SSL Labs提供的API接口進(jìn)行數(shù)據(jù)的獲取.

目前單進(jìn)程下可以完成平均每分鐘5個網(wǎng)站的測評速度.最終,從 SSL Labs 獲取的網(wǎng)站基礎(chǔ)配置數(shù)據(jù)存儲于MySQL本地數(shù)據(jù)庫中.

3.5 SSL/TLS協(xié)議密碼套件檢測模塊

我們將CipherScan嵌入到本系統(tǒng)中,以實(shí)現(xiàn)對目標(biāo)HTTPS服務(wù)器密碼套件掃描和分析.先部署所需要的Python運(yùn)行環(huán)境,然后通過Shell命令執(zhí)行腳本文件.

掃描結(jié)果以文件形式存儲于本地.

3.6 SSL/TLS協(xié)議攻擊測試模塊

TLS-Attacker雖然能對SSL/TLS開源組件(如OpenSSL、GnuTLS)的實(shí)現(xiàn)進(jìn)行主動測試,然而針對實(shí)際的HTTPS服務(wù)器卻會產(chǎn)生各種各樣的異常情況.因此,我們主要從以下三個方面對TLS-Attacker進(jìn)行改進(jìn):

(1)我們重新設(shè)計并實(shí)現(xiàn)了攻擊代碼的整體架構(gòu),修改代碼接口使其能夠?qū)χ付ǖ姆?wù)器進(jìn)行攻擊測試,并采用工廠模式來創(chuàng)建新的攻擊類型.

(2)為了加快攻擊測試,我們增加了多線程并發(fā)特性,并且注意到攻擊測試過程中消息等待時間限制等一系列SSL/TLS協(xié)議實(shí)現(xiàn)問題,通過設(shè)定超時時間或者在規(guī)定時間內(nèi)未響應(yīng)的請求進(jìn)行重新發(fā)送,這兩種方式解決了因?yàn)闀r間限制問題導(dǎo)致的攻擊異常.

(3)數(shù)據(jù)存儲方面,我們使用了Hibernate持久層框架,將攻擊測試結(jié)果存入MySQL本地數(shù)據(jù)庫,方便后期對數(shù)據(jù)進(jìn)行提取和分析.

4 實(shí)驗(yàn)結(jié)果與分析

所有實(shí)驗(yàn)均在一臺10核CPU、16 G內(nèi)存的CentOS服務(wù)器上進(jìn)行; 使用本測試系統(tǒng)的測試步驟如下:

(1)對Alexa排名前100萬網(wǎng)站進(jìn)行數(shù)據(jù)收集工作,并存儲于MySQL本地數(shù)據(jù)庫中;

(2)對數(shù)據(jù)庫中數(shù)據(jù)從基礎(chǔ)配置、密碼套件支持以及攻擊測試三方面進(jìn)行相關(guān)統(tǒng)計分析;

(3)結(jié)合當(dāng)前SSL/TLS協(xié)議安全現(xiàn)狀,對統(tǒng)計結(jié)果進(jìn)行更細(xì)致的分析;

(4)對掃描中發(fā)現(xiàn)的主要問題,提出相應(yīng)的解決方案或建議.

下面將從SSL/TLS協(xié)議基礎(chǔ)配置、密碼套件支持以及主流攻擊測試三方面詳細(xì)闡述相關(guān)實(shí)驗(yàn)結(jié)果.注意,下文中涉及到的所有表,如無特別說明,百分比 (%)均是指占全部HTTPS網(wǎng)站總數(shù)的百分比,SSL Pluse(%)是指SSL Pluse統(tǒng)計的百分比,PFS百分比(%)是指占所有 PFS 密碼套件的百分比,“-”表示 SSL Pluse 無此類統(tǒng)計數(shù)據(jù).

4.1 Web網(wǎng)站SSL/TLS協(xié)議基礎(chǔ)配置

目前,已使用該檢測系統(tǒng)完成Alexa排名前100萬網(wǎng)站的基礎(chǔ)配置數(shù)據(jù)收集與分析工作.從總體上來看,超過55.4%的網(wǎng)站可通過HTTPS訪問.下面從證書驗(yàn)證、協(xié)議版本、配置擴(kuò)展三方面進(jìn)行詳細(xì)分析與總結(jié).4.1.1 證書驗(yàn)證

(1)證書簽名算法

由表1可知,證書簽名算法以sha256WithRSA為主,占 86.1%; sha1WithRSA 在 2017 年即將被各大瀏覽器產(chǎn)商所淘汰,但目前仍然有5.3%的HTTPS網(wǎng)站使用該簽名算法.

(2)證書私鑰大小

由表2 可知,目前主要是 RSA 2048bits私鑰,占85.6%; 仍然有21個HTTPS網(wǎng)站使用1024bits的RSA私鑰; 更加高效又安全的ECDSA 256bits目前占到將近12%.

表1 證書簽名算法

表2 證書私鑰大小 (部分)

(3)證書鏈完整性

由表3可知,不完整證書鏈占到HTTPS網(wǎng)站的3.1%,而不受信證書證書占22.2%; 證書鏈的不完整并不一定說明證書不可信,因?yàn)榭梢酝ㄟ^加入可信中間CA證書的方式來構(gòu)造完整的證書鏈.

表3 證書鏈完整性 (基數(shù)是 709652 個 hosts)

4.1.2 協(xié)議版本

由表4可知,TLS1.2和TLS1.1已經(jīng)成為主流協(xié)議版本,都超過了 85%,相比于 SSL Pluse 的結(jié)果支持率更高; 仍然有12.3%的HTTPS網(wǎng)站支持不安全的TLS1.0及以下版本; 仍然存在少數(shù)網(wǎng)站支持或僅支持SSLv2或SSLv3,如有17個HTTPS網(wǎng)站僅支持SSLv2.

表4 協(xié)議版本

4.1.3 配置擴(kuò)展

由圖4可知,只有23.2%的HTTPS網(wǎng)站支持OCSP Stapling擴(kuò)展,而根據(jù)最新(2017年1月3日)的SSL Pluse顯示在其所調(diào)研的139741個網(wǎng)站中,有25.0%的網(wǎng)站支持 該擴(kuò)展,因此說明實(shí)際的HTTPS環(huán)境中,OCSP Stapling 擴(kuò)展的支持率更低,然而 OCSP Stapling這一擴(kuò)展對于緩解中間CA壓力、提高服務(wù)器響應(yīng)速度、改善用戶體驗(yàn)有著十分重要的作用,NIST guidelines[11]已經(jīng)將其作為關(guān)鍵擴(kuò)展,并規(guī)定所有SSL/TLS應(yīng)用都應(yīng)該實(shí)現(xiàn).

圖4 OCSP Stapling 擴(kuò)展

另外,我們還對重協(xié)商擴(kuò)展以及TLS壓縮算法進(jìn)行了調(diào)研分析,結(jié)果如下:

由表5、表6可知,根據(jù)我們的調(diào)研研究結(jié)果,不安全的重協(xié)商擴(kuò)展支持率為2.9%,而最新的SSL Pluse(2017年1月3日)的調(diào)查結(jié)果為1.1%,由于我們數(shù)據(jù)來源是Alexa排名前100萬的網(wǎng)站,而SSL Pluse只調(diào)研了139741個網(wǎng)站數(shù)據(jù),因此在調(diào)研方法相同的情況下,我們的數(shù)據(jù)說明了現(xiàn)實(shí)HTTPS環(huán)境中對不安全重協(xié)商擴(kuò)展的支持更為嚴(yán)重; 而由于支持TLS壓縮算法(zlib)導(dǎo)致 CRIME 攻擊[16]的網(wǎng)站,比 SSL Pluse 的調(diào)研結(jié)果要小將近0.7%,同理現(xiàn)實(shí)HTTPS環(huán)境中對TLS壓縮算法支持率更低.

表5 重協(xié)商擴(kuò)展

表6 TLS 壓縮算法擴(kuò)展

4.2 Web網(wǎng)站SSL/TLS協(xié)議密碼套件

總的來說,Alexa前100萬網(wǎng)站中有603391個網(wǎng)站開啟了SSL/TLS,占總數(shù)的60.3%.下面對這603391個網(wǎng)站從密鑰交換算法、會話密鑰強(qiáng)度、完美前向安全性等方面進(jìn)行分析.

4.2.1 會話密鑰強(qiáng)度

由表7可知:

(1)從文獻(xiàn)[17]中我們得知3DES安全性目前已經(jīng)和RC4屬于同一級別,然而由上表可知有532905個HTTPS網(wǎng)站(88.3%)支持3DES,相比之下RC4目前存在153525個HTTPS網(wǎng)站(25.4%)支持RC4密碼套件,因此不安全的3DES套件應(yīng)該開始引起重視;

(2)仍然存在少數(shù)HTTPS網(wǎng)站只支持3DES/RC4,優(yōu)先選擇3DES的占0.3%,優(yōu)先選擇RC4的占2.1%,仍然有1.1%的HTTPS網(wǎng)站強(qiáng)制在TLS1.1及以上版本中支持RC4;

(3)有8.8%的HTTPS服務(wù)器支持NULL、Export Key Exchange、RC4 等不安全的密碼套件,詳見 NIST guidelines[11]中對不安全密碼套件劃分.

表7 密碼套件掃描結(jié)果 (部分)

4.2.2 密鑰協(xié)商算法

由表8可知:

(1)密鑰協(xié)商算法主要以RSA和ECDHE為主,并且ECDHE支持率高過RSA;

(2)僅有2個HTTPS網(wǎng)站支持易導(dǎo)致Invalid Curve攻擊的ECDH密碼套件;

(3)仍然有少數(shù)HTTPS網(wǎng)站支持不安全的密鑰協(xié)商算法,如 ECDH/ADH/AECDH.

4.2.3 完美前向安全 (Perfect Forward Secrecy,PFS)

由表9可知:

(1)已經(jīng)有高達(dá)95.4%的HTTPS網(wǎng)站支持完美前向安全,并且有90.1%的HTTPS網(wǎng)站優(yōu)先選擇PFS密碼套件;

(2)雖然有超過32.5%的網(wǎng)站使用2048bits的DH參數(shù),但是使用不安全的1024bits的DH參數(shù)仍然高達(dá)19.2%,DH參數(shù)最高支持8192bits;

(3)在 ECDH 方面,主要使用曲線 P-256(82.9%)來完成握手,并且優(yōu)先選擇ECDH(P-256)套件的HTTPS網(wǎng)站高在77.1%.

表8 密鑰協(xié)商算法

表9 PFS(部分)

4.3 Web應(yīng)用SSL/TLS協(xié)議攻擊測試

目前,使用該檢測系統(tǒng)已完成Alexa前10萬網(wǎng)站的攻擊測試.檢測的攻擊有:Bleichanbacher[18]、Invalid-Curve[19]、Heartbleed[4]、POODLE[20]、PaddingOracle[21]以及CVE2016-2107[8],下面簡單介紹一下這幾種攻擊:

(1)Bleichanbacher攻擊[18]:敵手通過向服務(wù)器發(fā)送大量基于PKCS#1格式加密的消息,從得到的不同錯誤響應(yīng)消息中解密出預(yù)主密鑰,從而獲取TLS會話密鑰.

(2)InvalidCurve 攻擊[19]:某些橢圓曲線密碼學(xué)庫在處理輸入時忽略了“點(diǎn)是否位于曲線上”這一檢查,從而導(dǎo)致無效橢圓曲線攻擊,使得服務(wù)器私鑰泄露.

(3)Heartbleed 攻擊[4]:OpenSSL 在實(shí)現(xiàn) TLS 的心跳擴(kuò)展時沒有對輸入進(jìn)行適當(dāng)驗(yàn)證,導(dǎo)致敵手可以通過發(fā)送特定消息來引發(fā)緩沖區(qū)過讀,從而獲取服務(wù)器或客戶端的私密信息.

(4)POODLE 攻擊[20]:一種針對 SSLv3 的降級攻擊,由于SSL是先認(rèn)證后加密,使得MAC并沒有對Padding部分進(jìn)行保護(hù),從而導(dǎo)致敵手發(fā)起攻擊,獲取會話Cookie.

(5)PaddingOracle 攻擊[21]:它是一種針對 CBC 加密模式的攻擊,如果服務(wù)器對消息填充的有效性響應(yīng)不同的錯誤消息,那就說明可能存在該攻擊.

(6)CVE2016-2107 攻擊[8]:OpenSSL 開啟 AESNI后,對CBC模式填充檢測邏輯存在漏洞,且握手未完成時服務(wù)器報錯信息以明文返回,使得攻擊者可利用不同響應(yīng)來探測特定位置的字節(jié),從而解密明文.

由圖5可知:

(1)在所測試的 Alexa 前 10 萬網(wǎng)站中,HTTPS 訪問不可達(dá)網(wǎng)站將近75%,可能原因:部分國外網(wǎng)站國內(nèi)無法訪問,另一部分網(wǎng)站本身就不支持HTTPS;

(2)在 25217個 HTTPS訪問可達(dá)的網(wǎng)站中,有21669個(超過85%)網(wǎng)站存在或多或少的攻擊.

圖5 TLS-Attacker攻擊概覽

表10顯示了6種攻擊的測試總結(jié),由表可知:

(1)PaddingOracle攻擊和Poodle攻擊最為突出,分別占85.72%、12.84%;

(2)仍然有13 個網(wǎng)站存在HeartBleed攻擊,這13 個網(wǎng)站涵蓋購物、交友、保險金融以及視頻等領(lǐng)域;

(3)Invalid Curve 攻擊實(shí)現(xiàn)是針對 ECDH 密碼套件,沒有網(wǎng)站存在這類攻擊,說明所測試的網(wǎng)站中都不支持ECDH套件.

表10 TLS-Attacker攻擊結(jié)果

5 SSL/TLS 協(xié)議部署建議

通過對Alexa排名前100萬網(wǎng)站的檢測與分析,我們發(fā)現(xiàn)了SSL/TLS協(xié)議在Web應(yīng)用中部署實(shí)現(xiàn)時,在基礎(chǔ)配置、密碼套件支持以及攻擊測試方面存在的一些問題,現(xiàn)在針對以上發(fā)現(xiàn)的突出問題,給出以下解決方案或建議.

5.1 Web網(wǎng)站中SSL/TLS協(xié)議基礎(chǔ)配置建議

(1)證書.首先必須要從可信CA處獲取有效證書;然后要確保證書鏈的完整性,證書鏈可從CA中心獲取; 最后,至少選擇 SHA256 強(qiáng)度的簽名算法,如果目前仍然使用SHA1雜湊函數(shù)簽名,應(yīng)該立即進(jìn)行更新;

(2)私鑰.如果使用 RSA 證書,那么必須保證私鑰強(qiáng)度至少是2048bits; 如果使用ECDSA證書,私鑰強(qiáng)度至少為 256bits; 另外,從性能和效率上考慮,應(yīng)該優(yōu)先選擇ECDSA私鑰;

(3)協(xié)議版本.針對目前TLS各版本的安全現(xiàn)狀,只應(yīng)該支持TLS1.1或TLS1.2; 針對老客戶端兼容問題,應(yīng)該給客戶發(fā)送更新通知,使其更新到兼容版本,以支持安全的TLS版本; 在商用領(lǐng)域,不應(yīng)該為了兼容老客戶端,而部署不安全的SSL/TLS版本,從而導(dǎo)致更加嚴(yán)重的安全問題;

(4)配置擴(kuò)展.實(shí)現(xiàn) NIST guidelines[11]中規(guī)定的關(guān)鍵擴(kuò)展,如TLS證書狀態(tài)查詢擴(kuò)展(OCSP Stapling)、Trusted CA Indication以及服務(wù)器名稱指示擴(kuò)展(SNI)等.對于 HSTS(HTTP Strict Transport Security,HSTS)以及HSTS preloading這類優(yōu)秀擴(kuò)展,應(yīng)該盡量實(shí)現(xiàn),它們對于降低會話劫持風(fēng)險,抵御未知的新型攻擊具有很好的效果.

5.2 Web網(wǎng)站中SSL/TLS協(xié)議密碼套件支持建議

(1)使用更加安全的加密套件.根據(jù)現(xiàn)有的TLS1.3草案,未來TLS1.3協(xié)議規(guī)定只能使用128bit或者更強(qiáng)的加密認(rèn)證套件AEAD; 因此我們應(yīng)該禁用NULL、Export Key Exchange、RC4 以及 3DES 這些不安全的密碼套件,轉(zhuǎn)而使用更加安全的AEAD密碼套件;

(2)支持前向安全性.支持PFS能夠保證在私鑰泄露的情況下,以前的會話內(nèi)容也無法破解.因此,我們建議使用DHE或ECDHE密鑰協(xié)商算法,并且至少使用2048bits的DHE,或者256bits以上的ECDHE算法;

(3)控制加密套件的選擇.在進(jìn)行SSL/TLS協(xié)議握手過程中,對于客戶端發(fā)送過來的密碼套件列表,服務(wù)器應(yīng)該選擇其中安全性最高的密碼套件,而不應(yīng)該隨機(jī)選擇或者選擇第一個密碼套件.

5.3 Web網(wǎng)站中SSL/TLS協(xié)議主流攻擊防御建議

(1)關(guān)閉TLS壓縮,使其免遭CRIME攻擊;

(2)不要支持3DES密碼套件,使其免遭Sweet32攻擊;

(3)關(guān)閉 SSL2.0、SSL3.0 和 TLS1.0,防止 POODLE攻擊;

(4)使用安全的CBC加密模式套件,防止Beast、PaddingOracle攻擊;

(5)對于仍然遭受HeartBleed以及CVE2016-2107這類由于TLS開源組件實(shí)現(xiàn)漏洞導(dǎo)致的攻擊,應(yīng)該盡快更新其開源組件.

6 結(jié)語

針對SSL/TLS協(xié)議在Web應(yīng)用中部署配置方面存在的問題,本文首先設(shè)計并實(shí)現(xiàn)了針對Web網(wǎng)站的SSL/TLS協(xié)議配置安全檢測系統(tǒng),然后基于該檢測系統(tǒng)對Alexa排名前100萬網(wǎng)站的從基礎(chǔ)配置、密碼套件支持以及攻擊測試三個方面進(jìn)行了掃描,統(tǒng)計并分析了SSL/TLS協(xié)議部署配置情況,并發(fā)現(xiàn)了一些問題,如普遍支持不安全的3DES密碼套件、OCSP Stapling等關(guān)鍵擴(kuò)展部署率較低、仍然有不少網(wǎng)站存在HeartBleed嚴(yán)重攻擊等問題,針對上述問題本文最后給出了相應(yīng)的解決方案或建議.

1Dierks T.The Transport Layer Security (TLS)Protocol Version 1.2.IETF,RFC 5246.2008.

2Sawers P.Google:HTTPS now represents more than 50% of all pages loaded through Chrome on the desktop.http://venturebeat.com/2016/11/04/google-transparency-reporthttps/.[2016].

3Aas J.Mozilla telemetry shows more than 50% of page loads were HTTPS yesterday.First time that has ever happened.https://twitter.com/0xjosh/status/786971412959420424.[2016].

4Durumeric Z,Kasten J,Adrian D,et al.Thematter of heartbleed.Proc.of the 2014 Conference on Internet Measurement Conference.Vancouver,BC,Canada.2014.475–488.

5Zheng XF,Jiang J,Lian JJ,et al.Cookies lack integrity:Real-world implications.USENIX Security Symposiu.2015.707–721.

6Risti? I.Qualys SSL labs.https://www.ssllabs.com/index.html.

7Mozilla.CipherScan.https://github.com/mozilla/cipherscan.

8Somorovsky J.Systematic fuzzing and testing of TLS libra-ries.Proc.of the 2016 ACM SIGSAC Conference on Computer and Communications Security.Vienna,Austria.2016.1492–1504.

9Hodges J.How’s My SSL? https://www.howsmyssl.com/.

10SA HTB.High-tech bridge free SSL server test.https://www.htbridge.com/ssl/.[2015].

11Polk T,Mckay K,Chokhani S.Guidelines for the selection,configuration,and use of transport layer security (TLS)implementations.NIST Special Publication 800-52.U.S.Department of Commerce,2014.

12PCI Security Standards Council.Requirements and security assessment procedures.Wakefield,MA.USA:PCI Security Standards Council,2016.

13Centers for Disease Control and Prevention.HIPAA privacy rule and public health.Guidance from CDC and the U.S.Department of Health and Human Services.MMWR Suppl,2003,52:1–17.

14Risti? I.Ssl and Tls deployment best practices.https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices.[2017].

15Risti? I.Ssl labs Api documentation.https://www.ssllabs.com/projects/ssllabs-apis/index.html.[2016].

16Duong T,Rizzo J.The CRIME attack.Presentation at Ekoparty Security Conference.2012.

17Bhargavan K,Leurent G.On the practical (in-)security of 64-bit block ciphers:Collision attacks on HTTP over TLS and OpenVPN.Proc.of the 2016 ACM SIGSAC Conference on Computer and Communications Security.Vienna,Austria.2016.456–467.

18Nleichenbacher D.Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS# 1.Proc.of the 18th Annual International Cryptology Conference on Advances in Cryptology.London,UK.1998.1–12.

19Jager T,Schwenk J,Somorovsky J.Practical invalid curve attacks on TLS-ECDH.20th European Symposium on Research in Computer Security.Vienna,Austria.2015.407–425.

20M?ller B,Duong T,Kotowicz K.This poodle bites:Exploiting the SSL 3.0 fallback.Security Advisory,2014.

21Rizzo J,Duong T.Practical padding oracle attacks.Proc.of the 4th USENIX Conference on Offensive Technologies.Washington,DC,USA.2010.1–8.

Research on Security Vulnerability of SSL/TLS Protocol Configuration in Web Sites

HU Ren-Lin1,2,ZHANG Li-Wu21(University of Chinese Academy of Sciences,Beijing 100049,China)2(Institute of Software,Chinese Academy of Sciences,Beijing 100190,China)

The SSL/TLS protocol is one of the most widely used security protocols in communication security and identity authentication.It plays a very important role in ensuring the security of information system.However,due to the complexity of the SSL/TLS protocol,web sites are prone to security vulnerabilities such as code implementation vulnerabilities,deployment configuration defects and certificate key management problems when implementing and deploying SSL/TLS protocols.This type of security problems often occurs in Web sites,which also causes a lot of network security events,affecting a large number of sites.However,the existing methods to analyze and detect web security cannot satisfy the need.First,there are very few tools in this field,and their targets tend to focus on some certain aspects.In addition,these problems need to be further explored to acquire more detailed analysis and recommendations.In this paper,we design and implement a detection system to test the SSL/TLS protocol deployment of web site based on SSL/TLS.Our system performs vulnerability scanning and analysis mainly from three aspects:protocol basic configuration,cipher suites support,and typical attack test.We use it to scan the top 1 million websites of Alexa,and give detailed statistics and analysis.We found that the unsafe cipher suite 3DES is generally supported and the critical expansion OCSP Stapling support rate is less than 25%.What’s more serious is that there are still many sites suffering from HeartBleed attacks and many other serious problems.Finally,the corresponding solutions or suggestions are givenfor the main problems in the scanning results.

Web sites; SSL/TLS; security vulnerability scanning; protocol basic configuration; cipher suites

胡仁林,張立武.Web網(wǎng)站SSL/TLS協(xié)議配置安全研究.計算機(jī)系統(tǒng)應(yīng)用,2017,26(10):124–132.http://www.c-s-a.org.cn/1003-3254/5999.html

國家自然科學(xué)基金(61472409,61303247); 國家重點(diǎn)基礎(chǔ)研究計劃(973計劃)(2013CB338003)

2017-01-22; 采用時間:2017-02-17