Labs 導(dǎo)讀

HTTPS協(xié)議是最廣泛的互聯(lián)網(wǎng)應(yīng)用層協(xié)議標(biāo)準(zhǔn)，由HTTP加上TLS/SSL協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，主要通過(guò)數(shù)字證書(shū)、加密算法、非對(duì)稱密鑰等技術(shù)完成互聯(lián)網(wǎng)數(shù)據(jù)傳輸加密，實(shí)現(xiàn)互聯(lián)網(wǎng)傳輸安全保護(hù)。本文將從“保密性”“完整性”“有效性”這三個(gè)維度介紹HTTPS協(xié)議安全的緣由。

1

HTTPS協(xié)議安全是什么？

眾所周知，HTTP協(xié)議作為互聯(lián)網(wǎng)應(yīng)用層協(xié)議標(biāo)準(zhǔn)，并未對(duì)安全做過(guò)多的設(shè)計(jì)。從密碼學(xué)理論來(lái)分析，一個(gè)傳輸?shù)陌踩员仨毐ＷC三大基本要要素：（1）數(shù)據(jù)的保密性；（2）數(shù)據(jù)的完整性；（3）身份校驗(yàn)的安全性。

HTTPS簡(jiǎn)單理解成HTTP over SSL/TLS?？蛻舳撕头?wù)端在使用HTTPS傳輸業(yè)務(wù)數(shù)據(jù)前，首先由SSL/TLS協(xié)議在兩端之間建立安全信道（這個(gè)過(guò)程稱作握手協(xié)商階段），然后在該安全信道上對(duì)HTTP業(yè)務(wù)報(bào)文進(jìn)行加密傳輸（這個(gè)過(guò)程稱作加密數(shù)據(jù)傳輸階段）。接下來(lái)我們將從HTTP本身存在的安全問(wèn)題和HTTPS如何解決上述三個(gè)問(wèn)題來(lái)詳細(xì)論述HTTPS協(xié)議為什么安全。

圖1 HTTPvsHTTPS

2

HTTP通信傳輸存在的問(wèn)題

SSL/TLS的安全性體現(xiàn)在哪里，解決了哪些安全問(wèn)題，如何解決的，下面一步步介紹。

首先，先了解下客戶端和服務(wù)端之間使用明文HTTP通信存在的安全問(wèn)題。

圖2 HTTP安全問(wèn)題及HTTP到HTTPS的改造

關(guān)于HTTP協(xié)議的明文數(shù)據(jù)傳輸，攻擊者最常用的攻擊手法就是網(wǎng)絡(luò)嗅探，試圖從傳輸過(guò)程的數(shù)據(jù)包中分析出敏感的數(shù)據(jù)，例如管理員在Web程序后臺(tái)的登錄過(guò)程、用戶的隱秘信息（手機(jī)號(hào)碼、身份證號(hào)碼、信用卡號(hào)）等重要資料，可能導(dǎo)致嚴(yán)重的安全事故。

HTTP協(xié)議在傳輸客戶端請(qǐng)求和服務(wù)端響應(yīng)時(shí)，唯一的數(shù)據(jù)完整性檢驗(yàn)就是在報(bào)文頭部包含了本次傳輸數(shù)據(jù)的長(zhǎng)度，而對(duì)內(nèi)容是否被篡改不作確認(rèn)。因此攻擊者可以輕易的發(fā)動(dòng)中間人攻擊，修改客戶端和服務(wù)端傳輸?shù)臄?shù)據(jù)，甚至在傳輸數(shù)據(jù)中插入惡意代碼，導(dǎo)致客戶端被引導(dǎo)至惡意網(wǎng)站被植入木馬。

3

SSL/TLS協(xié)議的作用

SSL/TLS協(xié)議通過(guò)數(shù)字證書(shū)、非對(duì)稱密鑰、對(duì)稱加密算法、消息驗(yàn)證碼算法等技術(shù)，實(shí)現(xiàn)了通信雙方的身份驗(yàn)證、數(shù)據(jù)傳輸加密、防篡改等安全保護(hù)措施，其主要目標(biāo)是：

數(shù)據(jù)保密性：保證數(shù)據(jù)內(nèi)容在傳輸?shù)倪^(guò)程中不會(huì)被第三方查看，防止用戶數(shù)據(jù)信息的泄漏。

數(shù)據(jù)完整性：及時(shí)發(fā)現(xiàn)被第三方篡改的傳輸內(nèi)容，一旦發(fā)現(xiàn)數(shù)據(jù)被篡改過(guò)則拒絕接收。

身份校驗(yàn)安全性：保證數(shù)據(jù)到達(dá)用戶期望的目的地?？蛻舳诵枰?yàn)證目前正在通信的對(duì)端是否為期望的服務(wù)器，而非假冒的服務(wù)器。反之，服務(wù)器也可以對(duì)客戶端進(jìn)行有效性驗(yàn)證。

3.1 如何通過(guò)SSL/TLS協(xié)議實(shí)現(xiàn)數(shù)據(jù)保密性？

HTTPS中，數(shù)據(jù)保密性指對(duì)客戶端和服務(wù)端傳輸?shù)腍TTP明文數(shù)據(jù)進(jìn)行加密傳輸。使用的算法為對(duì)稱加密算法，如AES。數(shù)據(jù)保密性實(shí)現(xiàn)流程如下圖：

圖3 數(shù)據(jù)保密性實(shí)現(xiàn)流程

數(shù)據(jù)保密性需要通信雙方具有相同的密鑰，而且這個(gè)密鑰只能通信雙方知道，不能被第三方獲取。實(shí)際通信中，這個(gè)密鑰并不是固定不變的，也不會(huì)保存到磁盤文件中?？蛻舳嗣看魏头?wù)器建立新連接的時(shí)候，都會(huì)重新協(xié)商出相同的密鑰。在SSL/TLS協(xié)議的第一階段——握手協(xié)商階段，服務(wù)器和客戶端會(huì)交互一些報(bào)文信息，服務(wù)器和客戶端根據(jù)報(bào)文中的信息各自生成相同的密鑰，并把密鑰保存在內(nèi)存中。一旦這個(gè)連接斷開(kāi)，內(nèi)存中的密鑰將會(huì)自動(dòng)銷毀，避免密鑰的泄漏。

3.2 如何通過(guò)SSL/TLS協(xié)議實(shí)現(xiàn)數(shù)據(jù)完整性？

數(shù)據(jù)完整性用于防止HTTP數(shù)據(jù)被篡改，如果一旦發(fā)現(xiàn)數(shù)據(jù)被篡改則拒收數(shù)據(jù)包。使用的算法稱作消息驗(yàn)證碼算法(MAC)。數(shù)據(jù)完整性實(shí)現(xiàn)流程如下圖：

圖4 數(shù)據(jù)完整性實(shí)現(xiàn)流程

和數(shù)據(jù)保密性中的密鑰獲取方式一樣，這里的密鑰也是在SSL/TLS密鑰協(xié)商階段生成的、相同的、并保存在各自內(nèi)存中。

3.3 如何通過(guò)SSL/TLS協(xié)議實(shí)現(xiàn)身份校驗(yàn)的安全性？

HTTPS中，客戶端需要對(duì)通信端的身份有效性進(jìn)行校驗(yàn)，確定客戶端是和期望的真正服務(wù)端通信，而非和冒充的攻擊者進(jìn)行通信。

身份校驗(yàn)安全性主要利用數(shù)字證書(shū)技術(shù)實(shí)現(xiàn)。數(shù)字證書(shū)涉及的概念非常多，比如數(shù)字證書(shū)簽發(fā)、CA證書(shū)、根證書(shū)、證書(shū)鏈、證書(shū)有效性校驗(yàn)、非對(duì)稱密鑰算法、簽名/驗(yàn)證等，本文不做全面介紹，僅描述SSL/TLS涉及的概念：

3.3.1 非對(duì)稱密鑰算法

對(duì)稱密鑰算法中，加解密操作使用的密鑰是同一個(gè)，且通信雙方都需要知道這個(gè)密鑰。而非對(duì)稱密鑰算法有兩個(gè)密鑰，組成一個(gè)密鑰對(duì)；可以公開(kāi)的密鑰為公鑰，公鑰誰(shuí)都可以知道，不怕泄漏；需要保密不能泄露的密鑰稱為私鑰，私鑰只有自己知道，不能被泄漏；通信雙方的每一方，可以把自己的公鑰發(fā)送給對(duì)端，但自己的私鑰一定只有自己知道；同一份數(shù)據(jù)，使用公鑰加密，私鑰可以解密，反之，私鑰加密，公鑰可以解密。

圖5 非對(duì)稱密鑰用法一——通信數(shù)據(jù)加密傳輸

如圖5所示，在SSL/TLS協(xié)議中，存在使用非對(duì)稱密鑰算法對(duì)通信數(shù)據(jù)進(jìn)行加密傳輸?shù)牟僮?，在使用非?duì)稱密鑰算法對(duì)通信數(shù)據(jù)進(jìn)行加密傳輸?shù)膱?chǎng)景將使用圖5中左圖的流程。這里需要注意圖5右圖流程，公鑰是公開(kāi)的，誰(shuí)都可以知道，用私鑰加密的數(shù)據(jù)是不具有保密性的，因?yàn)橹灰獡碛泄€就能解密數(shù)據(jù)，所有竊聽(tīng)者都可以取到公鑰，都會(huì)看到真實(shí)數(shù)據(jù)內(nèi)容。實(shí)際上，圖5右圖“私鑰加密-公鑰解密”的使用場(chǎng)景稱作簽名的生成和校驗(yàn)，SSL/TLS協(xié)議也會(huì)用到，簽名生成和驗(yàn)證流程如下圖：

圖6 非對(duì)稱密鑰應(yīng)用二——通信數(shù)據(jù)簽名的生成及驗(yàn)證

私鑰加密的數(shù)據(jù)——簽名值——不具備保密性，但卻有校驗(yàn)作用。圖7中，通信數(shù)據(jù)是明文消息加上該消息的簽名值，簽名值用于對(duì)明文消息進(jìn)行校驗(yàn)，驗(yàn)證明文消息的正確性、是否被篡改過(guò)。

非對(duì)稱密鑰算法的用法，總結(jié)下來(lái)就是：

公鑰加密-私鑰解密?用于數(shù)據(jù)加密傳輸?通信數(shù)據(jù)是密文

私鑰加密-公鑰解密?用于簽名的生成和校驗(yàn)?通信數(shù)據(jù)是明文消息加上消息簽名值

3.3.2 數(shù)字證書(shū)

數(shù)字證書(shū)的簽發(fā)、數(shù)字證書(shū)的校驗(yàn)、證書(shū)鏈的相關(guān)細(xì)節(jié)，本文不做詳述，只要知道以下幾點(diǎn)：

①HTTP到HTTPS，客戶端和服務(wù)器涉及的一些改造，主要包括

服務(wù)端

-服務(wù)端需要針對(duì)某個(gè)服務(wù)配置SSL/TLS相關(guān)配置項(xiàng)，如密碼套件、證書(shū)/私鑰文件路徑。

-部署由CA機(jī)構(gòu)簽發(fā)的，包含服務(wù)器公鑰、服務(wù)器域名信息的數(shù)字證書(shū)，可公開(kāi)證書(shū)。

-部署和公鑰配對(duì)的私鑰文件，私鑰文件要具有一定安全保護(hù)措施，不能被泄漏。

客戶端

-瀏覽器配置CA證書(shū)、根證書(shū)等文件，一般默認(rèn)內(nèi)置。

②證書(shū)的使用主要在SSL/TLS協(xié)議握手協(xié)商階段，簡(jiǎn)述如下：

-客戶端和服務(wù)端建連后，在SSL/TLS協(xié)議握手協(xié)商階段初期，服務(wù)端將自己的數(shù)字證書(shū)發(fā)送給客戶端，服務(wù)端私鑰文件自己使用。

-客戶端收到服務(wù)器數(shù)字證書(shū)后，通過(guò)配置的CA證書(shū)、根證書(shū)，依據(jù)證書(shū)鏈的校驗(yàn)邏輯，驗(yàn)證服務(wù)器數(shù)字證書(shū)的有效性，一旦驗(yàn)證通過(guò)，說(shuō)明服務(wù)器身份正確。

-客戶端從數(shù)字證書(shū)中取出服務(wù)器公鑰，服務(wù)端從自己的私鑰文件中取出服務(wù)器私鑰。

之后，客戶端和服務(wù)端，就會(huì)使用這對(duì)非對(duì)稱密鑰進(jìn)行SSL/TLS協(xié)議握手協(xié)商階段的其他處理。RSA密鑰協(xié)商算法中使用了圖5的用法，而DHE、ECDHE密鑰協(xié)商算法中使用了圖6的用法。

4

總結(jié)

在互聯(lián)網(wǎng)快速發(fā)展的今天，網(wǎng)絡(luò)安全成為關(guān)系經(jīng)濟(jì)平穩(wěn)運(yùn)行和安全的重要因素，而隨著國(guó)際信息安全環(huán)境日趨復(fù)雜，西方加緊對(duì)我國(guó)的網(wǎng)絡(luò)遏制，并加快利用網(wǎng)絡(luò)進(jìn)行意識(shí)形態(tài)滲透，我國(guó)的網(wǎng)絡(luò)安全面臨嚴(yán)峻挑戰(zhàn)，中國(guó)移動(dòng)作為我國(guó)基礎(chǔ)網(wǎng)絡(luò)設(shè)施的運(yùn)營(yíng)商，未來(lái)將加速網(wǎng)絡(luò)安全方面的相關(guān)建設(shè)。

審核編輯 ：李倩