HTTPS(Hypertext Transfer Protocol Secure)協(xié)議用于提供安全的超文本傳輸服務(wù). 其本質(zhì)上是SSL/TLS層上的HTTP協(xié)議, 即所謂的"HTTP over SSL/TLS".

越來越多的WEB應(yīng)用需要在網(wǎng)絡(luò)上傳輸交易支付等敏感信息, 使用明文通信HTTP協(xié)議顯然無法滿足對安全性的要求, 因此正逐步被更安全的HTTPS所替代.

　　HTTP協(xié)議面對的安全威脅主要有三類:

冒充身份: 客戶端和服務(wù)端需要認(rèn)證對方的身份, 確認(rèn)自己不是在與冒充者通信. 比較典型的攻擊方式有中間人攻擊等.

竊聽風(fēng)險(xiǎn): 通信協(xié)議需要保證敏感的數(shù)據(jù)不會被未授權(quán)的第三方獲取.明文通信的HTTP協(xié)議很容易被竊取數(shù)據(jù).

數(shù)據(jù)篡改: 通信雙方需要驗(yàn)證來自對方的消息是完整的, 沒有丟失片段或被篡改. 攻擊者很容易攔截HTTP數(shù)據(jù)包, 修改數(shù)據(jù)后代替原包發(fā)送到目標(biāo)地址. 比如非常惱人的HTTP流量劫持.

傳輸層安全協(xié)議(Transport Layer Security, TLS)及其前身安全套接字層(Secure Sockets Layer, SSL)都旨在為WEB通信提供安全性和數(shù)據(jù)完整性保障.

TLS/SSL采用 非對稱加密握手-對稱加密通信 的方式來減少保密通信的計(jì)算量. 下面可以開始介紹TLS/SSL的握手過程了:

客戶端向服務(wù)端發(fā)出加密通信請求. 向服務(wù)端發(fā)送協(xié)議版本號, 支持的加密和壓縮方法, 以及一個隨機(jī)數(shù)random-client.

服務(wù)端響應(yīng), 確認(rèn)使用的協(xié)議版本號, 加密及壓縮算法以及隨機(jī)數(shù)random-server和服務(wù)端證書.

通常情況下只需要客戶端驗(yàn)證服務(wù)器端身份, 但是網(wǎng)銀等應(yīng)用中服務(wù)端需要驗(yàn)證客戶端身份. 這種情況下客戶端會在步驟3中發(fā)送自己的證書, 交由服務(wù)端驗(yàn)證.

此前介紹過的SSH協(xié)議密鑰協(xié)商原理與TLS/SSL非常類似. 不過SSH協(xié)議需要客戶端自行判斷是否信任服務(wù)端, 這對于WEB應(yīng)用來說顯然是不合適的.

注意到在上述密鑰交換方案中random-client和random-server都是明文交換的, 只有pre-master-key是加密傳輸?shù)?

為了進(jìn)一步提高安全性, HTTPS協(xié)議開始使用更安全的Diffie-Hellman算法把交換pre-master-key改為交換DH算法所需要的參數(shù).

握手階段結(jié)束后, 雙方確認(rèn)對方身份不是冒充者且建立起安全的對稱加密信道.

加密信道難以竊聽或篡改數(shù)據(jù)(指有目的性的篡改), 但是刪除數(shù)據(jù)片段就容易得多. 因此, HTTPS在通信過程中需要采取措施驗(yàn)證數(shù)據(jù)的完整性.

在HTTPS握手過程中除生成sessio-key外, 還會用類似的方法生成hash-key用于鑒證數(shù)據(jù)完整性.

HTTPS通信中, 雙方會用hash-key生成一個MAC(Message Authentication Code)附在HTTP報(bào)文后, 然后用session-key加密HTTP報(bào)文和MAC碼.

接收方在解密后會驗(yàn)證MAC值是否正確, 判斷數(shù)據(jù)是否被篡改.

現(xiàn)在介紹一下數(shù)字證書和認(rèn)證過程, 數(shù)字證書中通常包含幾個主要數(shù)據(jù):

簽發(fā)者 和 持有人(服務(wù)端)的機(jī)構(gòu), 域名等信息

服務(wù)端公鑰

證書到期時間

證書使用的加密算法和Hash算法

證書的數(shù)字簽名: 首先由證書正文生成hash值, 然后使用簽發(fā)者的私鑰進(jìn)行加密得到數(shù)字簽名

客戶端在校驗(yàn)服務(wù)端證書時會首先檢查是否信任簽發(fā)者以及證書是否過期等信息. 隨后根據(jù)證書正文生成hash值, 并用簽發(fā)者的公鑰解密簽名. 若解密得到的hash值與生成的hash值相同則說明證書有效.

若攻擊者想要冒充服務(wù)端進(jìn)行通信, 必須擁有一個密鑰對且公鑰包含在可信的證書中. 但是簽發(fā)者只會簽發(fā)包含真正服務(wù)端公鑰的證書, 攻擊者無法得到包含自己公鑰的證書.

若攻擊者試圖偽造證書, 攻擊者無法得到簽發(fā)者的私鑰也就無法生成合法的數(shù)字簽名, 無法偽造可信的證書.

也就是說除了服務(wù)端私鑰和簽發(fā)者私鑰保密外, 簽發(fā)者必須可靠(不會為攻擊者簽發(fā)證書) 才能保證不會有人冒充服務(wù)端.

TLS/SSL協(xié)議需要客戶端判斷是否信任簽發(fā)者, 用戶在判斷是否信任簽發(fā)者時需十分謹(jǐn)慎. 信任了不可靠的簽發(fā)者, 可能對通信安全造成嚴(yán)重威脅:

不可靠簽發(fā)者C為攻擊者A偽造了網(wǎng)站B的證書(證書的信息是網(wǎng)站B的, 但卻包含攻擊者A的公鑰).

當(dāng)用戶試圖與網(wǎng)站B進(jìn)行HTTPS通信時, 攻擊者A通過DNS劫持等手段使客戶端認(rèn)為A是網(wǎng)站B(此時客戶端并不信任與它通信的服務(wù)端).

若用戶信任了簽發(fā)者C, 則會信任其為A簽發(fā)的假證書(C當(dāng)然能生成合法的數(shù)字簽名), 即把攻擊者A當(dāng)做網(wǎng)站B. 此時攻擊者A可以獲得客戶端向網(wǎng)站發(fā)送的密碼等敏感信息,

A也可以冒充用戶與網(wǎng)站B通信, 在用戶不知情的情況下繼續(xù)監(jiān)聽加密通信. 這就是所謂的中間人攻擊.

本文永久更新鏈接地址：http://www.linuxidc.com/Linux/2018-01/150355.htm