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

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

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

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

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

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

安全通信原理握手過(guò)程

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

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

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

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

客戶端根據(jù)證書的簽發(fā)者和數(shù)字簽名確認(rèn)服務(wù)端可信. 確認(rèn)證書可信之后, 客戶端向服務(wù)端發(fā)送:由服務(wù)端公鑰加密過(guò)的隨機(jī)數(shù)pre-master-key, 服務(wù)端公鑰包含在服務(wù)端證書中編碼變更通知, 表示下一條消息開始客戶端將使用對(duì)稱加密通信. 會(huì)話密鑰session-key根據(jù)隨機(jī)數(shù)random-client, random-server和pre-master-key生成.服務(wù)端解密得到隨機(jī)數(shù)pre-master-key生成對(duì)話密鑰, 向客戶端返回編碼變更通知. 此后服務(wù)端使用同樣的會(huì)話密鑰進(jìn)行對(duì)稱加密通信. 至此握手階段結(jié)束, 安全信道建立.

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

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

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

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

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

通信過(guò)程

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

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

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

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

數(shù)字證書認(rèn)證原理

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

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

服務(wù)端公鑰

證書到期時(shí)間

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

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

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

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

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

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

不可靠的簽發(fā)者

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

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

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

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

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

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