HTTPS 加密與認證機制

時傾發表於2022-02-09
HTTP加密

HTTPS

HTTP 缺點：

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

為了統一解決上述這些問題，需要在 HTTP 上加入加密和認證等機制。即把新增了加密及認證機制的 HTTP 稱為 HTTPS（HTTP Secure）。

HTTPS

HTTPS 並非是應用層的一種新協議，而是 HTTP 通訊介面部分用 SSL 或 TLS 協議代替而已。 在採用 SSL 後，HTTP 就擁有了加密、證書和完整性保護這些功能。
通常，HTTP 直接和 TCP 通訊。當使用 SSL 時，則演變成先和 SSL通訊，再由 SSL和 TCP 通訊。
image-20220209164817275.png

SSL: Secure Socket Layer，安全套接層，主要任務是提供私密性，資訊完整性和身份認證。SSL 獨立於 HTTP 協議，位於TCP/IP協議與各種應用層協議之間，其他執行在應用層的 SMTP 和 Telnet 等協議均可配合 SSL 協議使用。SSL 是當今世界上應用最為廣泛的網路安全技術。具體可檢視 SSL/TLS協議詳解
TLS: Transport Layer Security，安全層傳輸協議
HTTPS：HTTP Secure，超文字傳輸安全協議

HTTPS 混合加密機制

HTTPS 採用對稱加密與非對稱加密兩者並用的混合加密機制，充分利用了兩者各自的優勢。

對稱加密

加密和解密使用同一個金鑰的方式稱為對稱加密。
對稱加密時必須將金鑰也發給對方。

為什麼不只採用對稱加密？

如果通訊雙方都各自持有同一個金鑰，且沒有洩漏出去，則這兩方的通訊就是安全的。然而問題是如何讓傳輸雙方都安全的知道金鑰？。

如果由伺服器生成一個金鑰並傳輸給瀏覽器，此時通訊被監聽，那麼金鑰就可能會落入攻擊者之手，就失去了加密的意義。
如果瀏覽器內部預存了網站 A 的金鑰，且可以確保除了瀏覽器和網站A，不會有任何一方知道該金鑰，理論上用對稱加密是可以的。只要瀏覽器預存好世界上所有 HTTPS 網站的金鑰就行了！這麼做顯然不現實。
image-20220209165220501.png

非對稱加密

非對稱加密很好地解決了對稱加密的缺點。加密和解密使用不同金鑰的方式稱為非對稱加密。
所以非對稱加密有兩把金鑰，一把是私有金鑰（private key），另一把是公開金鑰（public key）。私鑰加密的資訊只有公鑰才能解開， 公鑰加密的資訊只有私鑰可以解開。為什麼會這樣呢？因為RSA演算法。

RSA 演算法

RSA 演算法計算流程如下:

  1. 隨機選取兩個質數p和q
  2. 計算 n = pq
  3. 計算 φ(n) = (p-1)(q-1)
  4. 找一個與φ(n)互質的小奇數e，互質是指兩個數的公約數只有1
  5. 對模φ(n)，計算e的乘法逆元d，即找到一個d，使下列等式成立：(e*d) mod φ(n) = 1
  6. 得到公鑰：(e, n)，私鑰： (d, n)
  7. 加密過程：c = (m^e) mod n, （c為加密後的密文，m為原文）
  8. 解密過程：m = (c^d) mod n

為什麼公鑰自己加密的資料自己還解不出來？因為加密演算法(m^e) mod n是模運算，模運算是不能反解的。例如 5 對 4 取模，5 % 4 =1 ，但是反過來，知道 x % 4 = 1，求 x。這個x可以有無限個，5，9，13... 所以即使有公鑰(e,n) 和密文 c，也不知道(m^e) 到底取哪個值，這就是非對稱加密的核心機密。私鑰加密同理，自己加密的自己也反解不出來。

為什麼不只採用非對稱加密？

因為非對稱加密非常耗時，效率低，而對稱加密會快很多，所以應儘量減少非對稱加密的次數。
image-20220209171559100.png

混合加密機制的請求過程

  1. 某網站擁有用於非對稱加密的公鑰A、私鑰A’。
  2. 瀏覽器請求該網站伺服器，伺服器把公鑰A 明文 傳輸到瀏覽器。
  3. 瀏覽器隨機生成一個用於對稱加密的金鑰 X，用公鑰 A 加密後傳給伺服器。
  4. 伺服器拿到後用私鑰A’ 解密得到金鑰 X。
  5. 雙方都擁有金鑰X，之後雙方所有資料都通過金鑰 X 加密解密即可。
為什麼公鑰明文傳輸？
如果對公鑰加密傳輸，就變成了變成雞生蛋、蛋生雞的問題...

此時看起來一切都很完美，但是如何證明瀏覽器收到的公鑰一定是該網站的公鑰呢？如果請求被攻擊：

  1. 某網站有用於非對稱加密的公鑰A、私鑰A’。
  2. 瀏覽器向網站伺服器請求，伺服器把公鑰A 明文 傳輸到瀏覽器。
  3. 攻擊者劫持到公鑰 A，儲存下來，把資料包中的公鑰A 替換成偽造的公鑰B（攻擊者擁有公鑰B 對應的私鑰 B’）。
  4. 瀏覽器生成一個用於對稱加密的金鑰X，用公鑰B（瀏覽器無法得知公鑰被替換了）加密後傳給伺服器。
  5. 攻擊者劫持後用私鑰B’ 解密得到金鑰 X，再用公鑰A 加密後傳給伺服器。
  6. 伺服器拿到後用私鑰A’ 解密得到金鑰 X。

此時雙方都不會發現異常。造成這種情況的根本原因是瀏覽器無法確認收到的公鑰是不是正確的。

數字證書

綜上所述，瀏覽器無法證明收到的公鑰是該網站的公鑰。為了解決這個問題，就出現了數字證書。數字證書是由數字證書認證機構（CA，Certificate Authority）給服務端頒發的。（CA機構是客戶端與伺服器雙方都可信賴的第三方權威機構。）

CA機構通過服務端提供的相關資訊生成證書，一個數字證書通常包含了：

  • 公鑰；
  • 持有者資訊；
  • 證書認證機構（CA）的資訊；
  • CA 對這份檔案的數字簽名及使用的演算法；
  • 證書有效期；
  • 其他額外資訊...

瀏覽器控制檯可以看數字證書。百度的數字證書如下：

如何防止證書被篡改？

為了避免對證書內容的篡改，出現了數字簽名 Certificate Signature。 CA 機構把網站的公鑰、用途、頒發者、有效時間等基本資訊打成一個包，然後對這些資訊進行 Hash 計算，得到一個 Hash 值；然後 CA 機構使用自己的私鑰將該 Hash 值加密生成數字簽名，也就是 CA 對證書做了簽名。

image-20220209183354560.png

業務流程

  1. 伺服器向 CA 機構提出數字證書的申請，CA 機構在判明提出申請者的身份之後，將公鑰、用途、頒發者、有效時間，數字簽名，雜湊演算法等資訊生成數字證書，併傳送給服務端。
  2. 伺服器會將這份數字證書傳送給客戶端， 接到證書的客戶端使用 CA機構的公開金鑰，對數字證書進行驗證。

  3. 客戶端使用同樣的 Hash 演算法獲取該證書的 Hash 值 H1；使用 CA 的公鑰解密數字簽名得到一個 Hash 值 H2 ；比較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認為證書不可信。
    如果證書驗證通過，客戶端便可明確兩件事：

    • 認證伺服器的公開金鑰的是真實有效的數字證書認證機構。
    • 數字證書的公開金鑰是值得信賴的。
  4. 證書驗證通過後，客戶端生成用於對稱加密的金鑰X，用公鑰加密後傳給伺服器。
  5. 伺服器拿到後用私鑰A 解密得到金鑰 X。之後的通訊就由金鑰X 實現加密解密。

image-20220209181800602.png

為什麼製作數字簽名時需要 hash？

因為進行 hash 演算法之後得到的是一個定長的 hash 碼（比如用 md5 演算法 hash 後可以得到固定的128位的值）。接受者用私鑰解密出來的得到一個 hash 碼，再用 hash 演算法對訊息內容進行 hash 得到一個新的 hash 碼，只需要比較解密出來的 hash 碼和 hash 內容出來的兩個定長 hash碼就可以；這樣做比起沒有hash，直接加密和解密訊息內容效能更好。

怎麼證明 CA 機構的公鑰是可信的？

CA 機構的公開金鑰必須安全地轉交給客戶端。使用通訊方式時，如何安全轉交是一件很困難的事，因此，多數瀏覽器會事先在內部植入常用認證機關的公開金鑰。以此來保證 CA 機構的公鑰是可信的。(雞生蛋 蛋生雞的問題...)

證書鏈

敬請期待～～

相關文章