HTTP基礎06--網絡安全

HTTP 的缺點

通訊使用明文可能會被竊聽

• HTTP 報文使用明文（指未通過加密的報文）方式發送。

通訊的加密

• 用 SSL 創建安全通訊線路以後，就能夠在這條線路上進行 HTTP 通訊了。與 SSL 組合使用的 HTTP 被稱爲 HTTPS（HTTP Secure，超文本傳輸安全協議）或 HTTP over SSL。

內容的加密

• 將參與通訊的內容自己加密的方式。因爲 HTTP 協議中沒有加密機制，那麼就對 HTTP 協議傳輸的內容自己加密。即把 HTTP 報文裏所含的內容進行加密處理。

• 因爲該方式不一樣於 SSL 或 TLS 將整個通訊線路加密處理，因此內容仍有被篡改的風險。

不驗證通訊方的身份就可能遭遇假裝

• 任何人均可發起請求: 在 HTTP 協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發起請求。另外，服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的 IP 地址和端口號沒有被 Web 服務器設定限制訪問的前提下）。

• 查明對手的證書:雖然使用 HTTP 協議沒法肯定通訊方，但若是使用 SSL 則能夠。SSL 不只提供加密處理，並且還使用了一種被稱爲證書的手段，可用於肯定方。

沒法證實報文完整性，可能已遭篡改

• 接收到的內容可能有誤:因爲 HTTP 協議沒法證實通訊的報文完整性，所以，在請求或響應送出以後直到對方接收以前的這段時間內，即便請求或響應的內容遭到篡改，也沒有辦法獲悉。

• 如何防止篡改:雖然有使用 HTTP 協議肯定報文完整性的方法，但事實上並不便捷、可靠。

HTTP+ 加密 + 認證 + 完整性保護 =HTTPS

HTTPS 是身披 SSL 外殼的 HTTP

• SSL 是獨立於 HTTP 的協議，因此不光是 HTTP 協議，其餘運行在應用層的 SMTP 和 Telnet 等協議都可配合 SSL 協議使用。能夠說 SSL 是當今世界上應用最爲普遍的網絡安全技術。

相互交換密鑰的公開密鑰加密技術

• SSL 採用一種叫作公開密鑰加密的加密處理方式。

• 共享密鑰加密的困境

• 使用兩把密鑰的公開密鑰加密

• HTTPS 採用混合加密機制

證實公開密鑰正確性的證書

*公開密鑰加密方式仍是存在一些問題的。那就是沒法證實公開密鑰自己就是貨真價實的公開密鑰;爲了解決上述問題，可使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。

HTTPS 的安全通訊機制

• 步驟 1： 客戶端經過發送 Client Hello 報文開始 SSL 通訊。報文中包含客戶端支持的 SSL 的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。

• 步驟 2： 服務器可進行 SSL 通訊時，會以 Server Hello 報文做爲應答。和客戶端同樣，在報文中包含 SSL 版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。

• 步驟 3： 以後服務器發送 Certificate 報文。報文中包含公開密鑰證書。

• 步驟 4： 最後服務器發送 Server Hello Done 報文通知客戶端，最初階段的 SSL 握手協商部分結束。

• 步驟 5： SSL 第一次握手結束以後，客戶端以 Client Key Exchange 報文做爲迴應。報文中包含通訊加密中使用的一種被稱爲 Pre-master secret 的隨機密碼串。該報文已用步驟 3 中的公開密鑰進行加密。

• 步驟 6： 接着客戶端繼續發送 Change Cipher Spec 報文。該報文會提示服務器，在此報文以後的通訊會採用 Pre-master secret 密鑰加密。

• 步驟 7： 客戶端發送 Finished 報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定標準。

• 步驟 8： 服務器一樣發送 Change Cipher Spec 報文。

• 步驟 9： 服務器一樣發送 Finished 報文。

• 步驟 10： 服務器和客戶端的 Finished 報文交換完畢以後，SSL 鏈接就算創建完成。固然，通訊會受到 SSL 的保護。今後處開始進行應用層協議的通訊，即發送 HTTP 請求。

• 步驟 11： 應用層協議通訊，即發送 HTTP 響應。

• 步驟 12： 最後由客戶端斷開鏈接。斷開鏈接時，發送 close_notify 報文。上圖作了一些省略，這步以後再發送 TCP FIN 報文來關閉與 TCP 的通訊。

HTTPS 也存在一些問題，那就是當使用 SSL 時，它的處理速度會變慢。