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

胡仁林 ,張立武

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

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

胡仁林1,2,張立武2

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

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

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

1 引言

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

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

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

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

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

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

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

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

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

2 相關工作

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

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

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

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

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

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

3.1 設計目標

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

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

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

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

3.2 設計思想

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 實驗結(jié)果與分析

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

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

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

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

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

下面將從SSL/TLS協(xié)議基礎配置、密碼套件支持以及主流攻擊測試三方面詳細闡述相關實驗結(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é)議基礎配置

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

(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%; 證書鏈的不完整并不一定說明證書不可信,因為可以通過加入可信中間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 配置擴展

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

圖4 OCSP Stapling 擴展

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

由表5、表6可知,根據(jù)我們的調(diào)研研究結(jié)果,不安全的重協(xié)商擴展支持率為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)實HTTPS環(huán)境中對不安全重協(xié)商擴展的支持更為嚴重; 而由于支持TLS壓縮算法(zlib)導致 CRIME 攻擊[16]的網(wǎng)站,比 SSL Pluse 的調(diào)研結(jié)果要小將近0.7%,同理現(xiàn)實HTTPS環(huán)境中對TLS壓縮算法支持率更低.

表5 重協(xié)商擴展

表6 TLS 壓縮算法擴展

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

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

4.2.1 會話密鑰強度

由表7可知:

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

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

(3)有8.8%的HTTPS服務器支持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)站支持易導致Invalid Curve攻擊的ECDH密碼套件;

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

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

由表9可知:

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

(2)雖然有超過32.5%的網(wǎng)站使用2048bits的DH參數(shù),但是使用不安全的1024bits的DH參數(shù)仍然高達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應用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]:敵手通過向服務器發(fā)送大量基于PKCS#1格式加密的消息,從得到的不同錯誤響應消息中解密出預主密鑰,從而獲取TLS會話密鑰.

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

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

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

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

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

由圖5可知:

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

(2)在 25217個 HTTPS訪問可達的網(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)站涵蓋購物、交友、保險金融以及視頻等領域;

(3)Invalid Curve 攻擊實現(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應用中部署實現(xiàn)時,在基礎配置、密碼套件支持以及攻擊測試方面存在的一些問題,現(xiàn)在針對以上發(fā)現(xiàn)的突出問題,給出以下解決方案或建議.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6 結(jié)語

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

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é)議配置安全研究.計算機系統(tǒng)應用,2017,26(10):124–132.http://www.c-s-a.org.cn/1003-3254/5999.html

國家自然科學基金(61472409,61303247); 國家重點基礎研究計劃(973計劃)(2013CB338003)

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