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

眾所周知，HTTP協(xié)議作為互聯(lián)網(wǎng)應(yīng)用層協(xié)議標(biāo)準(zhǔn)，并未對(duì)安全做過多的設(shè)計(jì)。從密碼學(xué)理論來分析，一個(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è)過程稱作握手協(xié)商階段），然后在該安全信道上對(duì)HTTP業(yè)務(wù)報(bào)文進(jìn)行加密傳輸（這個(gè)過程稱作加密數(shù)據(jù)傳輸階段）。接下來我們將從HTTP本身存在的安全問題和HTTPS如何解決上述三個(gè)問題來詳細(xì)論述HTTPS協(xié)議為什么安全。

圖1 HTTPvsHTTPS

二、HTTP通信傳輸存在的問題

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

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

圖2 HTTP安全問題及HTTP到HTTPS的改造

關(guān)于HTTP協(xié)議的明文數(shù)據(jù)傳輸，攻擊者最常用的攻擊手法就是網(wǎng)絡(luò)嗅探，試圖從傳輸過程的數(shù)據(jù)包中分析出敏感的數(shù)據(jù)，例如管理員在Web程序后臺(tái)的登錄過程、用戶的隱秘信息（手機(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)站被植入木馬。

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

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

• 數(shù)據(jù)保密性：保證數(shù)據(jù)內(nèi)容在傳輸?shù)倪^程中不會(huì)被第三方查看，防止用戶數(shù)據(jù)信息的泄漏。
• 數(shù)據(jù)完整性：及時(shí)發(fā)現(xiàn)被第三方篡改的傳輸內(nèi)容，一旦發(fā)現(xiàn)數(shù)據(jù)被篡改過則拒絕接收。
• 身份校驗(yàn)安全性：保證數(shù)據(jù)到達(dá)用戶期望的目的地?？蛻舳诵枰?yàn)證目前正在通信的對(duì)端是否為期望的服務(wù)器，而非假冒的服務(wù)器。反之，服務(wù)器也可以對(duì)客戶端進(jìn)行有效性驗(yàn)證。

3.1 如何通過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è)連接斷開，內(nèi)存中的密鑰將會(huì)自動(dòng)銷毀，避免密鑰的泄漏。

3.2 如何通過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 如何通過SSL/TLS協(xié)議實(shí)現(xiàn)身份校驗(yàn)的安全性？

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

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

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

對(duì)稱密鑰算法中，加解密操作使用的密鑰是同一個(gè)，且通信雙方都需要知道這個(gè)密鑰。而非對(duì)稱密鑰算法有兩個(gè)密鑰，組成一個(gè)密鑰對(duì)；可以公開的密鑰為公鑰，公鑰誰都可以知道，不怕泄漏；需要保密不能泄露的密鑰稱為私鑰，私鑰只有自己知道，不能被泄漏；通信雙方的每一方，可以把自己的公鑰發(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右圖流程，公鑰是公開的，誰都可以知道，用私鑰加密的數(shù)據(jù)是不具有保密性的，因?yàn)橹灰獡碛泄€就能解密數(shù)據(jù)，所有竊聽者都可以取到公鑰，都會(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)證明文消息的正確性、是否被篡改過。

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

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

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

3.3.2 數(shù)字證書

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

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

• 服務(wù)端

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

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

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

• 客戶端

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

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

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

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

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

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

四、總結(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)商，未來將加速網(wǎng)絡(luò)安全方面的相關(guān)建設(shè)。