HTTP圖解學習記錄（七）

風吹過wu發表於2018-09-13
HTTP圖解

確保Web安全的HTTPS

HTTP的缺點

HTTP主要有這些不足

  • 通訊使用明文（不加密），內容可能會被竊聽
  • 不驗證通訊方的身份，因此可能遭遇偽裝
  • 無法證明報文的完整性，所以有可能已遭篡改

除此之外，HTTP 本身還有很多缺點。而且，還有像某些特定的 Web 伺服器和特定的 Web 瀏覽器在實際應 用中存在的不足（也可以說成是脆弱性或安全漏洞），另外，用 Java 和 PHP 等程式語言開發的 Web 應用也 可能存在安全漏洞。

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

  • TCP/IP是可能被竊聽的網路

HTTP圖解學習記錄（七）

  • 加密處理防止被竊聽

通訊的加密

種方式就是將通訊加密。HTTP 協議中沒有加密機制，但可以通過和 SSL（Secure Socket Layer，安 全套接層）或 TLS（Transport Layer Security，安全層傳輸協議）的組合使用，加密 HTTP 的通訊內 容。

用 SSL 建立安全通訊線路之後，就可以在這條線路上進行 HTTP 通訊了。與 SSL 組合使用的 HTTP 被稱為 HTTPS

HTTP圖解學習記錄（七）

內容的加密

HTTP圖解學習記錄（七）

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

  • 任何人都可發起請求

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

  • 查明對手的證照

雖然使用 HTTP 協議無法確定通訊方，但如果使用 SSL 則可以。SSL 不僅提供加密處理，而且還使用 了一種被稱為證照的手段，

可用於確定方。 證照由值得信任的第三方機構頒發，用以證明伺服器和客戶端是實際存在的。另外，偽造證照從技術角 度來說是異常困難的一件事。所以只要能夠確認通訊方（伺服器或客戶端）持有的證照，即可判斷通訊 方的真實意圖。

HTTP圖解學習記錄（七）

無法證明報文完整性，可能已遭篡改

HTTP圖解學習記錄（七）

為了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認證和加密處理及摘要功能。僅靠 HTTP 確保 完整性是非常困難的，因此通過和其他協議組合使用來實現這個目標

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

HTTP圖解學習記錄（七）

HTTPS是身披SSL外殼的HTTP

HTTPS 並非是應用層的一種新協議。只是 HTTP 通訊介面部分用 SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。

通常，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL 和 TCP 通訊了。簡言 之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的 HTTP。

HTTP圖解學習記錄（七）

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

SSL 採用一種叫做公開金鑰加密（Public-key cryptography）的加密處理方式。 近代的加密方法中加密演算法是公開的，而金鑰卻是保密的。通過這種方式得以保持加密方法的安全性。

加密和解密都會用到金鑰。沒有金鑰就無法對密碼解密，反過來說，任何人只要持有金鑰就能解密了。如果 金鑰被攻擊者獲得，那加密也就失去了意義。

  • 共享祕鑰加密的困境

HTTP圖解學習記錄（七）

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

公開金鑰加密使用一對非對稱的金鑰。一把叫做私有金鑰（private key），另一把叫做公開金鑰（public key）。顧名思義，私有金鑰不能讓其他任何人知道，而公開金鑰則可以隨意釋出，任何人都可以獲得

  • HTTPS採用混合加密機制

HTTPS 採用共享金鑰加密和公開金鑰加密兩者並用的混合加密機制。若金鑰能夠實現安全交換，那麼有 可能會考慮僅使用公開金鑰加密來通訊。但是公開金鑰加密與共享金鑰加密相比，其處理速度要慢。 所以應充分利用兩者各自的優勢，將多種方法組合起來用於通訊。在交換金鑰環節使用公開金鑰加密方 式，之後的建立通訊交換報文階段則使用共享金鑰加密方式。

HTTP圖解學習記錄（七）

 證明公開金鑰正確性的

  • 可證明組織真實性的 EV SSL
  • 用以確認客戶端的客戶端證照
  • 認證機構信譽
  • 由自認證機構頒發的證照稱為自簽名

HTTPS的安全通訊機制

HTTP圖解學習記錄（七）
步驟 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 的通訊。

在以上流程中，應用層傳送資料時會附加一種叫做 MAC（Message Authentication Code）的報文摘要。 MAC 能夠查知報文是否遭到篡改，從而保護報文的完整性。

SSL 的慢分兩種。一種是指通訊慢。另一種是指由於大量消耗 CPU 及記憶體等資源，導致處理速度變 慢。

和使用 HTTP 相比，網路負載可能會變慢 2 到 100 倍。除去和 TCP 連線、傳送 HTTP 請求 • 響應以 外，還必須進行 SSL 通訊，因此整體上處理通訊量不可避免會增加。

另一點是 SSL 必須進行加密處理。在伺服器和客戶端都需要進行加密和解密的運算處理。因此從結果上 講，比起 HTTP 會更多地消耗伺服器和客戶端的硬體資源，導致負載增強。

相關文章