基于個人移動端的SSL協(xié)議安全技術(shù)與教學(xué)應(yīng)用

2021-07-06 02:10:22李明坤胡曦明

計算機技術(shù)與發(fā)展 2021年6期

李明坤，胡曦明,2*，李鵬,2

(1.陜西師范大學(xué) 計算機科學(xué)學(xué)院，陜西西安 710119；2.現(xiàn)代教學(xué)技術(shù)教育部重點實驗室，陜西西安 710119)

0 引言

作為提供信息加密、身份驗證和完整性驗證等安全服務(wù)支撐HTTPS安全鏈接的SSL協(xié)議(secure sockets layer)，面臨會話劫持攻擊、剝離攻擊和數(shù)據(jù)密文解密攻擊等多種攻擊[1-4]。有關(guān)移動終端的SSL安全分析表明，安智網(wǎng)和360手機安卓市場近6萬個應(yīng)用軟件中約有59.25%的應(yīng)用軟件使用了與SSL相關(guān)的API，存在可信證書鏈缺陷的軟件占77.1%，SSL錯誤忽略缺陷的軟件占比33.29%，不可信證書鏈攻擊成功的軟件占比17.39%，無域名認證攻擊成功的軟件占比15.22%[5]；即使大部分網(wǎng)絡(luò)銀行類APP完整實現(xiàn)了SSL證書公鑰綁定，也依然存在諸多安全隱患。

反觀高校SSL協(xié)議安全技術(shù)應(yīng)用發(fā)展現(xiàn)狀：一方面，SSL協(xié)議作為計算機相關(guān)專業(yè)的教學(xué)重點得到了廣泛關(guān)注和持續(xù)研究；但另一方面，SSL協(xié)議安全技術(shù)長期停留于基于PC真機或仿真平臺局限在學(xué)校實驗室的內(nèi)部網(wǎng)絡(luò)環(huán)境中實施的傳統(tǒng)模式，例如：華南師范大學(xué)石碩基于“PC+服務(wù)器”開展SSL實驗[6]；海南經(jīng)貿(mào)職業(yè)技術(shù)學(xué)院黃雪琴采用仿真平臺開展SSL協(xié)議實驗[7]；溫州大學(xué)黃輝使用ASA模擬器開展SSL實驗[8]。在高校建設(shè)面向移動互聯(lián)網(wǎng)新經(jīng)濟深化產(chǎn)教融合培養(yǎng)網(wǎng)絡(luò)安全卓越工程師的背景下，探索在真實的移動互聯(lián)網(wǎng)環(huán)境下，基于手機、筆記本電腦和PAD等設(shè)備的新型SSL協(xié)議個人移動安全技術(shù)和實驗應(yīng)用成為了富有時代性、緊迫性和教育價值的新課題。

1 SSL協(xié)議及其安全機制

1.1 SSL協(xié)議

SSL協(xié)議在TCP/IP分層模型中工作在傳輸層和應(yīng)用層之間，為互聯(lián)網(wǎng)環(huán)境中的兩個通信進程提供安全及數(shù)據(jù)完整性保障。從協(xié)議體系結(jié)構(gòu)上來看，SSL協(xié)議分為上下兩個協(xié)議子層，上層是SSL握手協(xié)議簇(SSL Handshake Protocol)，具體包括SSL握手協(xié)議(SSL Handshake Protocol)、修改密文協(xié)議(Change Cipher Protocol)和告警協(xié)議(Alert Protocol)；下層是SSL記錄協(xié)議(SSL Record Protocol)，具體定義了兩種報文，分別為發(fā)送信息報文(Send Information Packet)和接受信息報文(Accept Information Packet)。

SSL握手協(xié)議負責(zé)通信雙方的身份驗證、參數(shù)協(xié)商和交換密鑰以建立安全的加密通道，修改密文協(xié)議負責(zé)將參數(shù)更新信息進行加密、壓縮并告知對端，告警協(xié)議負責(zé)在通信異常時向?qū)Χ税l(fā)出警告或致命兩類報文。SSL記錄協(xié)議分別定義了發(fā)送信息報文和接受信息報文，接受信息報文對接收的加密數(shù)據(jù)進行解密、合并和傳輸，發(fā)送信息報文則對發(fā)送數(shù)據(jù)進行加密、分組和傳輸。

1.2 SSL安全機制

如圖1所示，SSL記錄協(xié)議首先將應(yīng)用數(shù)據(jù)分為多個片段并對片段進行壓縮，隨后附上由安全哈希協(xié)議或消息摘要等算法生成的加密MAC作為消息身份驗證代碼，然后根據(jù)雙方協(xié)商的加密方式與參數(shù)對數(shù)據(jù)進行加密，最后封裝SSL首部[9]。SSL握手協(xié)議簇通過客戶端和服務(wù)器之間四個階段的會話協(xié)商機制，建立起安全的數(shù)據(jù)傳輸通道，具體過程如下。

圖1 SSL協(xié)議安全機制

(1)Hello階段。

客戶端與服務(wù)器分別向?qū)Ψ桨l(fā)送ClientHello和SeverHello報文，客戶端發(fā)送一個隨機數(shù)給服務(wù)器，客戶端與服務(wù)器相互交換加密套件(Support Ciphers)與版本信息(SSL Version)等安全信息。

(2)服務(wù)器認證階段。

服務(wù)器向客戶端發(fā)送Certificate、Server Key Exchange和ServerHello Done等身份證書報文實現(xiàn)自身身份驗證并與客戶端交換公鑰與參數(shù)。在Certificate報文中，服務(wù)器需要向客戶端發(fā)送整個證書鏈，包括服務(wù)器CA(數(shù)位憑證認證機構(gòu))、中間CA以及到達可信的根CA所需要的所有中間證書。大部分公共簽名機構(gòu)CA不直接在服務(wù)器證書上簽名，中間CA是由根CA對其簽名驗證的，由根CA離線存儲以保證信息的安全。個人移動端一般僅信任根CA，這樣服務(wù)商同樣需要向其他CA申請證書，多級遞進確保證書的安全。在SSL協(xié)議握手期間服務(wù)器會向客戶端發(fā)送整個證書鏈。

(3)客戶端發(fā)送共享密鑰和加密套件階段。

客戶端首先向服務(wù)器發(fā)送包含組裝共享密鑰的預(yù)主密鑰、一個隨機數(shù)和加密套件的Client Key Exchange報文，服務(wù)器收到預(yù)主密鑰后，將預(yù)主密鑰與收到的兩個隨機數(shù)組合生成共享密鑰，然后通過Change Cipher Spec報文通知服務(wù)器之后的報文會用共享密鑰加密，在此基礎(chǔ)上客戶端發(fā)送握手信息摘要經(jīng)加密成的Encrypted Handshake Message報文，以便于服務(wù)器驗證共享密鑰的有效性。

(4)服務(wù)器發(fā)送用戶注冊信息階段。

服務(wù)器向客戶端發(fā)送包含客戶端登陸會話所需Session信息的New Session Ticket報文，然后發(fā)送Change Cipher Spec報文通知客戶端之后的報文同樣采用共享密鑰加密，最后服務(wù)器同樣發(fā)送Encrypted Handshake Message報文將握手信息摘要發(fā)送給客戶端，以便于客戶端接受后確認共享密鑰的有效性。

2 SSL協(xié)議安全技術(shù)設(shè)計

在分析SSL協(xié)議和SSL安全機制的基礎(chǔ)上，該文探索基于手機、筆記本電腦等個人移動端在真實互聯(lián)網(wǎng)環(huán)境下構(gòu)建SSL協(xié)議安全技術(shù)系統(tǒng)，實現(xiàn)輕量化、便攜化的SSL協(xié)議攻擊與防御。

2.1 總體架構(gòu)

基于個人移動端的SSL協(xié)議安全技術(shù)總體架構(gòu)包含四個模塊，如圖2所示。

圖2 基于個人移動端的SSL協(xié)議安全技術(shù)總體架構(gòu)

(1)攻擊方模塊：由筆記本電腦組成，與服務(wù)器和客戶端在同一網(wǎng)絡(luò)環(huán)境下，負責(zé)對客戶端模塊進行證書偽造攻擊、跳轉(zhuǎn)篡改攻擊等SSL攻擊操作。

(2)SSL服務(wù)器模塊：由內(nèi)容服務(wù)器組成，負責(zé)與客戶端建立HTTPS鏈接。由于攻擊對象為SSL客戶端，該安全技術(shù)不會對服務(wù)器造成任何不良影響，因此既可以自行搭建私網(wǎng)服務(wù)器，也可以采用公網(wǎng)的服務(wù)器。該文以百度服務(wù)器與163郵箱服務(wù)器為例，以更加真實地測試SSL安全。

(3)SSL客戶端模塊：由手機、PAD等個人移動設(shè)備組成，與服務(wù)器建立HTTPS鏈接，作為被攻擊方。

(4)數(shù)據(jù)測量與分析模塊：由筆記本電腦組成，負責(zé)對SSL攻擊進行數(shù)據(jù)測量和可視化分析，而如何從SSL客戶端獲取數(shù)據(jù)是安全技術(shù)的難點。

2.2 技術(shù)環(huán)節(jié)

基于個人移動端的SSL協(xié)議安全技術(shù)環(huán)節(jié)如圖3所示。

圖3 基于個人移動端的SSL協(xié)議安全技術(shù)環(huán)節(jié)

技術(shù)環(huán)節(jié)總體上分為：搭建環(huán)境、攻擊與防御、測量分析。首先采用“個人移動端+內(nèi)容服務(wù)器”搭建技術(shù)環(huán)境，在此基礎(chǔ)上可以開展X.509證書偽造、鏈接跳轉(zhuǎn)篡改和繞過SSL綁定攻擊等多種SSL典型攻擊以及ARP防御、反向驗證和安全開發(fā)與使用等防御，在實現(xiàn)過程中通過實時抓包分析、證書解密等方法實現(xiàn)對實現(xiàn)過程的數(shù)據(jù)測量和可視化分析。

3 SSL協(xié)議安全技術(shù)實現(xiàn)

3.1 個人移動端配置

整個安全技術(shù)需要基于手機、筆記本電腦等個人移動端設(shè)備完成SSL攻擊、防御與測量分析等一系列復(fù)雜功能，包括證書偽造、鏈接跳轉(zhuǎn)篡改、手機抓包等，而這部分正是整個安全技術(shù)的難點所在。該文以常見的X.509證書偽造攻擊和鏈接跳轉(zhuǎn)篡改攻擊為例，實現(xiàn)過程中使用到的設(shè)備有一臺HP 8GRAM+1TROM/I5 /GTX1050TI筆記本電腦，作為攻擊方和數(shù)據(jù)測量與分析的設(shè)備；一臺MI 驍龍835/6GRAM+64GROM手機，作為客戶端和數(shù)據(jù)測量與分析的設(shè)備；一臺SSL服務(wù)器 BAIDU HTTPS SERVER/163 HTTPS SERVER，作為SSL服務(wù)器。

在此基礎(chǔ)上，該安全技術(shù)所用的手機和筆記本電腦等個人移動設(shè)備配置方法，如圖4所示，包括關(guān)鍵步驟、詳細操作和工具實例。

圖4 個人移動端軟件環(huán)境配置

3.2 X.509證書偽造攻擊

(1)攻擊原理。

在SSL客戶端訪問一個基于SSL加密的Web時，需要三個步驟驗證證書服務(wù)器的有效性[10]：①該證書的主題名與訪問服務(wù)站點的名稱一致性；②該證書的有效期限；③該證書與證書鏈中數(shù)字簽名的匹配。若以上步驟有任意一個沒有通過，SSL協(xié)議就會向客戶端發(fā)出警告，指出證書存在安全問題。此時需要用戶來決定是否繼續(xù)使用，攻擊方由此利用用戶安全意識缺乏進行攻擊，若用戶選擇信任不安全的證書，或者被攻擊方惡意控制將偽造的證書加入信任列表，從而造成基于X.509證書偽造的SSL會話劫持攻擊。

(2)實現(xiàn)流程。

基于X.509證書偽造的攻擊流程如下：

①HTTPS連接協(xié)商：攻擊方同時與客戶端、服務(wù)器發(fā)出HTTPS連接協(xié)商，攻擊方截獲并轉(zhuǎn)發(fā)客戶端與服務(wù)器之間的所有請求與響應(yīng)。當攻擊方截獲客戶端發(fā)給服務(wù)器的ClientHello請求時，記錄隨機序列在內(nèi)的相關(guān)信息之后再轉(zhuǎn)發(fā)給服務(wù)器。

②攻擊方代替客戶端對服務(wù)器進行驗證：該步驟為證書偽造攻擊的關(guān)鍵步驟，當攻擊方截獲服務(wù)器發(fā)給客戶端的響應(yīng)及服務(wù)器證書時，保存包括隨機序列和session的相關(guān)信息，將數(shù)據(jù)包中的證書重組替換為偽造的X.509證書，重新打包數(shù)據(jù)之后轉(zhuǎn)發(fā)給客戶端。

③攻擊方截獲服務(wù)器與客戶端交換的密鑰：客戶端發(fā)送密鑰給服務(wù)器，攻擊方截獲密鑰再轉(zhuǎn)發(fā)給服務(wù)器，若服務(wù)器要求對客戶端進行認證，則攻擊方需要截獲用戶證書并重新打包轉(zhuǎn)發(fā)。

④攻擊方基于偽造的X.509證書實施攻擊：攻擊方利用偽造的證書同時和服務(wù)器與客戶端建立HTTPS鏈接，但服務(wù)器與客戶端并不知道攻擊方作為中間人劫持了HTTPS鏈接，隨后服務(wù)器與客戶端之間傳輸?shù)臄?shù)據(jù)都可以被攻擊方明文解析。

(3)操作與關(guān)鍵配置。

X.509證書偽造攻擊在攻擊方和被攻擊方通過命令行輸入命令和瀏覽器建立HTTPS鏈接等方式，共需要五個步驟完成。X.509證書偽造攻擊的操作步驟與關(guān)鍵配置如表1所示。

表1 X.509證書偽造攻擊操作與關(guān)鍵配置

(4)數(shù)據(jù)測量與可視化分析。

根據(jù)被攻擊方抓包得到的報文可以看到攻擊方保持了證書id等外部信息不變，但實則替換了證書內(nèi)部的加密協(xié)商相關(guān)字段值，由此達到攻擊方可以明文解密被攻擊方與服務(wù)器之間HTTPS鏈接的目的。

攻擊方進行X.509證書偽造攻擊之后，使用fiddler對被攻擊方的HTTPS訪問請求進行抓包分析，如圖5所示。攻擊方從截獲的報文中可以監(jiān)控被攻擊方的網(wǎng)絡(luò)訪問記錄，本例訪問了百度移動端站點www.m.baidu.com；在此基礎(chǔ)上，攻擊方通過X.509證書偽造攻擊可以進一步竊取被攻擊方的個人私密信息，如被攻擊方的cookie值。在被攻擊方通過HttpCanary抓包，可以驗證攻擊方竊取的cookie值的真實性。

圖5 證書對比分析

3.3 鏈接跳轉(zhuǎn)篡改攻擊

(1)攻擊原理。

使用者在申請HTTPS鏈接時有兩種實現(xiàn)方式[11]，一種是在輸入網(wǎng)址時添加前綴https://指定該鏈接為HTTPS鏈接，另一種是使用者如果沒有指定鏈接是HTTP還是HTTPS，瀏覽器會默認為HTTP類型，此時跳轉(zhuǎn)到HTTPS就需要利用HTTP的302狀態(tài)來重定向為HTTPS鏈接。大部分人圖方便并不會采用第一種實現(xiàn)方式，而第二種實現(xiàn)方式就給了攻擊方攻擊的機會[12]。一個完全由SSL加密的HTTPS通信變成了加密的HTTPS通信和明文傳輸?shù)腍TTP會話混合的傳輸方式，如果HTTP通信被劫持，那么HTTPS會話也會遭到劫持。

(2)實現(xiàn)流程。

基于鏈接跳轉(zhuǎn)篡改攻擊流程如下：

①HTTPS鏈接協(xié)商：攻擊方分別向客戶端、服務(wù)器發(fā)出HTTP和HTTPS鏈接協(xié)商，攻擊方截獲并轉(zhuǎn)發(fā)客戶端與服務(wù)器之間的所有請求與響應(yīng)。

②攻擊方替換服務(wù)器HTTPS流量中的信息：攻擊方截獲服務(wù)器發(fā)給客戶端的HTTPS流量，攻擊方解析該數(shù)據(jù)包并將其中的替換成，將Location:https://...替換成Location:http://..，保存修改的URL后，重新打包數(shù)據(jù)并轉(zhuǎn)發(fā)給客戶端。

③攻擊方轉(zhuǎn)發(fā)修改客戶端HTTP流量中的信息：攻擊方截獲并解析客戶端發(fā)給服務(wù)器的HTTP請求，與之前保存的URL對比之后，若存在要修改的HTTP URL，則替換為原HTTPS URL，重新打包數(shù)據(jù)并轉(zhuǎn)發(fā)給服務(wù)器。

④攻擊方維持與客戶端和服務(wù)器之間的虛假HTTPS鏈接：分別與客戶端和服務(wù)器維持HTTP和HTTPS鏈接。

(3)操作與關(guān)鍵配置。

鏈接跳轉(zhuǎn)篡改攻擊在攻擊方和被攻擊方通過命令行輸入命令和瀏覽器建立HTTPS鏈接等方式，共需要四個步驟完成。鏈接跳轉(zhuǎn)篡改攻擊的操作步驟與關(guān)鍵配置如表2所示。