HTTPS原理淺析

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

愈來愈多的WEB應用須要在網絡上傳輸交易支付等敏感信息, 使用明文通訊HTTP協議顯然沒法知足對安全性的要求, 所以正逐步被更安全的HTTPS所替代.

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

• 冒充身份: 客戶端和服務端須要認證對方的身份, 確認本身不是在與冒充者通訊. 比較典型的攻擊方式有中間人攻擊等.

• 竊聽風險: 通訊協議須要保證敏感的數據不會被未受權的第三方獲取.明文通訊的HTTP協議很容易被竊取數據.

• 數據篡改: 通訊雙方須要驗證來自對方的消息是完整的, 沒有丟失片斷或被篡改. 攻擊者很容易攔截HTTP數據包, 修改數據後代替原包發送到目標地址. 好比很是惱人的HTTP流量劫持.

安全通訊原理

握手過程

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

TLS/SSL採用 非對稱加密握手-對稱加密通訊 的方式來減小保密通訊的計算量. 下面能夠開始介紹TLS/SSL的握手過程了:

1. 客戶端向服務端發出加密通訊請求. 向服務端發送協議版本號, 支持的加密和壓縮方法, 以及一個隨機數random-client.

2. 服務端響應, 確認使用的協議版本號, 加密及壓縮算法以及隨機數random-server和服務端證書.

3. 客戶端根據證書的簽發者和數字簽名確認服務端可信. 確認證書可信以後, 客戶端向服務端發送:

• 由服務端公鑰加密過的隨機數pre-master-key, 服務端公鑰包含在服務端證書中
• 編碼變動通知, 表示下一條消息開始客戶端將使用對稱加密通訊. 會話密鑰session-key根據隨機數random-client, random-server和pre-master-key生成.

1. 服務端解密獲得隨機數pre-master-key生成對話密鑰, 向客戶端返回編碼變動通知. 此後服務端使用一樣的會話密鑰進行對稱加密通訊. 至此握手階段結束, 安全信道創建.

一般狀況下只須要客戶端驗證服務器端身份, 可是網銀等應用中服務端須要驗證客戶端身份. 這種狀況下客戶端會在步驟3中發送本身的證書, 交由服務端驗證.

此前介紹過的SSH協議密鑰協商原理與TLS/SSL很是相似. 不過SSH協議須要客戶端自行判斷是否信任服務端, 這對於WEB應用來講顯然是不合適的.

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

爲了進一步提升安全性, HTTPS協議開始使用更安全的Diffie-Hellman算法把交換pre-master-key改成交換DH算法所須要的參數.

握手階段結束後, 雙方確認對方身份不是冒充者且創建起安全的對稱加密信道.

通訊過程

加密信道難以竊聽或篡改數據(指有目的性的篡改), 可是刪除數據片斷就容易得多. 所以, HTTPS在通訊過程當中須要採起措施驗證數據的完整性.

在HTTPS握手過程當中除生成sessio-key外, 還會用相似的方法生成hash-key用於鑑證數據完整性.

HTTPS通訊中, 雙方會用hash-key生成一個MAC(Message Authentication Code)附在HTTP報文後, 而後用session-key加密HTTP報文和MAC碼.

接收方在解密後會驗證MAC值是否正確, 判斷數據是否被篡改.

數字證書

認證原理

如今介紹一下數字證書和認證過程, 數字證書中一般包含幾個主要數據:

1. 簽發者 和 持有人(服務端)的機構, 域名等信息

2. 服務端公鑰

3. 證書到期時間

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

5. 證書的數字簽名: 首先由證書正文生成hash值, 而後使用簽發者的私鑰進行加密獲得數字簽名

客戶端在校驗服務端證書時會首先檢查是否信任簽發者以及證書是否過時等信息. 隨後根據證書正文生成hash值, 並用簽發者的公鑰解密簽名. 若解密獲得的hash值與生成的hash值相同則說明證書有效.

若攻擊者想要冒充服務端進行通訊, 必須擁有一個密鑰對且公鑰包含在可信的證書中. 可是簽發者只會簽發包含真正服務端公鑰的證書, 攻擊者沒法獲得包含本身公鑰的證書.

若攻擊者試圖僞造證書, 攻擊者沒法獲得簽發者的私鑰也就沒法生成合法的數字簽名, 沒法僞造可信的證書.

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

不可靠的簽發者

TLS/SSL協議須要客戶端判斷是否信任簽發者, 用戶在判斷是否信任簽發者時需十分謹慎. 信任了不可靠的簽發者, 可能對通訊安全形成嚴重威脅:

1. 不可靠簽發者C爲攻擊者A僞造了網站B的證書(證書的信息是網站B的, 但卻包含攻擊者A的公鑰).

2. 當用戶試圖與網站B進行HTTPS通訊時, 攻擊者A經過DNS劫持等手段使客戶端認爲A是網站B(此時客戶端並不信任與它通訊的服務端).

3. 若用戶信任了簽發者C, 則會信任其爲A簽發的假證書(C固然能生成合法的數字簽名), 即把攻擊者A當作網站B. 此時攻擊者A能夠得到客戶端向網站發送的密碼等敏感信息,

4. A也能夠冒充用戶與網站B通訊, 在用戶不知情的狀況下繼續監聽加密通訊. 這就是所謂的中間人攻擊.