胡仁林 ,張立武

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

Web網站SSL/TLS協議配置安全研究①

胡仁林1,2,張立武2

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

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

Web 網站; SSL/TLS 協議; 安全漏洞掃描; 基礎配置; 密碼套件

1 引言

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

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

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

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

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

SSL Pluse統計數據不全面,受限于網站管理人員是否愿意公開其網站配置信息;

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

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

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

2 相關工作

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

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

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

2.1 組織結構

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

3 Web 網站 SSL/TLS 協議配置安全檢測系統設計與實現

3.1 設計目標

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

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

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

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

3.2 設計思想

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

3.3 系統架構

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

圖1 系統邏輯層次圖

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

圖2 安全配置分析檢測內容示意圖

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

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

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

3.4 SSL/TLS協議基礎配置檢測模塊

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

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

圖3 SSL Labs接口調用示意圖

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

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

3.5 SSL/TLS協議密碼套件檢測模塊

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

掃描結果以文件形式存儲于本地.

3.6 SSL/TLS協議攻擊測試模塊

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

(1)我們重新設計并實現了攻擊代碼的整體架構,修改代碼接口使其能夠對指定的服務器進行攻擊測試,并采用工廠模式來創(chuàng)建新的攻擊類型.

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

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

4 實驗結果與分析

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

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

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

(3)結合當前SSL/TLS協議安全現狀,對統計結果進行更細致的分析;

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

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

4.1 Web網站SSL/TLS協議基礎配置

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

(1)證書簽名算法

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

(2)證書私鑰大小

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

表1 證書簽名算法

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

(3)證書鏈完整性

由表3可知,不完整證書鏈占到HTTPS網站的3.1%,而不受信證書證書占22.2%; 證書鏈的不完整并不一定說明證書不可信,因為可以通過加入可信中間CA證書的方式來構造完整的證書鏈.

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

4.1.2 協議版本

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

表4 協議版本

4.1.3 配置擴展

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

圖4 OCSP Stapling 擴展

另外,我們還對重協商擴展以及TLS壓縮算法進行了調研分析,結果如下:

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

表5 重協商擴展

表6 TLS 壓縮算法擴展

4.2 Web網站SSL/TLS協議密碼套件

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

4.2.1 會話密鑰強度

由表7可知:

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

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

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

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

4.2.2 密鑰協商算法

由表8可知:

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

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

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

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

由表9可知:

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

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

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

表8 密鑰協商算法

表9 PFS(部分)

4.3 Web應用SSL/TLS協議攻擊測試

目前,使用該檢測系統已完成Alexa前10萬網站的攻擊測試.檢測的攻擊有: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 在實現 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 萬網站中,HTTPS 訪問不可達網站將近75%,可能原因:部分國外網站國內無法訪問,另一部分網站本身就不支持HTTPS;

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

圖5 TLS-Attacker攻擊概覽

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

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

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

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

表10 TLS-Attacker攻擊結果

5 SSL/TLS 協議部署建議

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

5.1 Web網站中SSL/TLS協議基礎配置建議

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

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

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

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

5.2 Web網站中SSL/TLS協議密碼套件支持建議

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

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

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

5.3 Web網站中SSL/TLS協議主流攻擊防御建議

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

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

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

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

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

6 結語

針對SSL/TLS協議在Web應用中部署配置方面存在的問題,本文首先設計并實現了針對Web網站的SSL/TLS協議配置安全檢測系統,然后基于該檢測系統對Alexa排名前100萬網站的從基礎配置、密碼套件支持以及攻擊測試三個方面進行了掃描,統計并分析了SSL/TLS協議部署配置情況,并發(fā)現了一些問題,如普遍支持不安全的3DES密碼套件、OCSP Stapling等關鍵擴展部署率較低、仍然有不少網站存在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網站SSL/TLS協議配置安全研究.計算機系統應用,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