從HTTP到HTTPS

打瞌睡的布偶貓發表於2021-06-26
HTTP

從HTTP到HTTPS

HTTP存在的缺陷

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

防竊聽

通訊加密

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

用SSL建立安全通訊線路之後，就可以在這條線路上進行 HTTP 通訊了。

使用安全通訊線路通訊，不僅防竊聽，還能防篡改。

SSL + HTTP == HTTPS。

image-20210626141604616

內容加密

對 HTTP 協議傳輸的內容本身加密，即把 HTTP 報文主體內容進行加密處理。為了做到有效的內容加密，前提是要求客戶端和伺服器同時具備加密和解密機制。

image-20210626142050825

需要注意的是，這裡加密的內容仍能被竊聽，而且加密的內容仍可能受到中間人攻擊，即傳輸內容有被篡改的風險。

防偽裝

檢視證書

SSL 不僅提供加密處理，而且還使用了一種被稱為證書的手段，可用於確定對方的身份。證書由值得信任的第三方機構頒發，用以證明伺服器和客戶端是實際存在的。另外，偽造證書從技術角度來說異常困難。所以只要能夠確認通訊方（伺服器或客戶端）持有的證書，即可判斷通訊方的真實意圖。

image-20210626142739141

通過使用證書，以證明通訊方就是預料中的伺服器。這對使用者個人來講，也減少了個人資訊洩露的危險性。

防篡改

雜湊值校驗MD5 + 數字簽名

可用MD5和SHA-1等雜湊值校驗的方法以及確認檔案的數字簽名方法（以PGP建立的數字簽名為例）來保證報文的完整性，但是當PGP和MD5本身被篡改時，報文的完整性依舊無法保證。PGP 是用來證明建立檔案的數字簽名，MD5 是由單向函式生成的雜湊值。

認證加密 + 報文摘要

僅靠HTTP保證報文的完整性是非常困難的，需要藉助組合SSL協議來實現。SSL 提供認證和加密處理及報文摘要功能，能夠保障報文的完整性。

HTTPS概述

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

image-20210626143928301

HTTPS的加密、認證、完整性保護都是通過SSL協議完成的。

因此，HTTPS就是身披SSL協議的HTTP。只是HTTP的通訊介面部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。

通常，HTTP直接和TCP通訊。使用SSL後，先和SSL通訊，再由SSL和TCP通訊。

image-20210626144351374

不光是 HTTP 協議，其他執行在應用層的 SMTP 和 Telnet 等協議均可配合 SSL 協議使用。可以說 SSL 是當今世界上應用最為廣泛的網路安全技術。

加密技術

共享金鑰加密

加密和解密同用一個金鑰的方式稱為共享金鑰加密（Common key crypto system），所以也被叫做對稱金鑰加密。

image-20210626144853818

以共享金鑰方式加密時必須將金鑰也發給對方，而傳送金鑰就有被竊聽的風險，如果金鑰被攻擊者獲得，那加密也就失去了意義。如果不傳送，對方就不能解密。再說，金鑰若能夠安全傳送，那資料也應該能安全送達。

公開金鑰加密

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

使用公開金鑰加密方式，傳送密文的一方使用對方的公開金鑰進行加密處理，對方收到被加密的資訊後，再使用自己的私有金鑰進行解密。利用這種方式，不需要傳送用來解密的私有金鑰，也不必擔心金鑰被攻擊者竊聽而盜走。

image-20210626145407521

想根據密文和公開金鑰，恢復到資訊原文是異常困難的， 因為解密過程就是在對離散對數進行求值，這並非輕而易舉就能辦到。

公開金鑰正確性驗證 —— 防公開金鑰偽造

在與某伺服器建立公開金鑰加密通訊時，無法證明收到的公開金鑰就是原本預想的那臺伺服器發行的公開金鑰。或許在公開金鑰傳輸途中，真正的公開金鑰已經被攻擊者替換掉了。

為了驗證公開金鑰的正確性，可以使用數字證書認證機構CA和其相關機關頒發的公開金鑰證書。

真正安全的公開金鑰加密通訊過程如下圖所示：

image-20210626150258099

混合加密

使用公開金鑰加密，能實現資訊的安全交換，但公開金鑰加密處理起來比共享金鑰加密方式更為複雜，因此若在通訊時使用公開金鑰加密方式，效率就很低。

考慮兩種加密方式各自的優勢，可以採取混合加密的方式進行通訊，即在交換金鑰環節使用公開金鑰加密方式，之後的建立通訊交換報文階段則使用共享金鑰加密方式。

image-20210626145751739

HTTPS通訊

從僅使用伺服器端公開金鑰（伺服器證書）建立HTTPS通訊的整個過程如下圖所示：

image-20210626151221090

  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報文。

報文完整性保護

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

HTTP vs HTTPS

特性 HTTP HTTPS
防竊聽 × √（共享金鑰加密）
防偽裝 × √（證書）
防篡改 × √（MAC報文摘要）
通訊速度 快 比HTTP慢2到100倍
通訊成本 低 高（多為證書費用）

相關文章