HTTPS 是如何進行安全傳輸的 ？

肖卫卫讲编程發表於2024-05-07
HTTP

概述

現代密碼學對資訊的處理主要離不開以下的三種形式：

  1. 摘要：主要用於資料校驗，例如儲存密碼等，摘要是對資訊進行單向的雜湊，改變資訊的原有形態，因為雜湊函式的特點是易變性（即使微小的變化也會產生完全不同的雜湊值），而且無法被反向推匯出來，例如上文提到常見的雜湊加密方式有：MD2/4/5/6、SHA0/1/256/512 演算法等方式。
  2. 加密：主要用於保證資訊的安全傳輸，確保真實的資訊只能被授權的人訪問（擁有金鑰），通常使用金鑰對資訊進行加密，和摘要不同的是，加密是可以解密為明文資訊的。金鑰的型別又分為：對稱型金鑰，非對稱型金鑰（公鑰、私鑰）等，常見的有 DES、AES、RC4、IDEA 等方式。
  3. 簽名：主要是用來保證明文資訊的完整性、真實性和檢查是否被篡改的一種方式（使用雜湊函式），例如 jwt 令牌 中就是有一段簽名，用於保證負載資訊的真實性，簽名並不保證資訊的私密性。

總體來說，它們的分工是：

  • 摘要：用於確保資料的完整性和快速比較，無法被解密。
  • 加密：用於保護資料的機密性，它和摘要的區別是加密可以逆向破解，也就是解密。
  • 簽名：則提供了一種驗證訊息來源和完整性的方法。但資訊是公開的。

這三者共同構成了現代密碼學的基石，廣泛應用於資料保護、身份驗證和網路安全等領域。

金鑰

對稱型金鑰

對稱加密

對稱型金鑰加密的基本原理是將明文資料透過一個加密演算法和一個金鑰轉換成密文，然後接收方使用相同的金鑰和解密演算法將密文還原成原始的明文。由於加密和解密都使用同一個金鑰，因此被稱為對稱加密。對稱型金鑰加密演算法的特點是演算法簡單、速度快，適合於大量資料的加密。常見的對稱型金鑰加密演算法包括：AES (Advanced Encryption Standard)、DES (Data Encryption Standard)、3DES (Triple DES)。

對稱型金鑰在金鑰的保管和分發上面存在困難，因為金鑰必須安全地分發給所有需要它的使用者，並且每次通訊都需要一個新的金鑰，這在大規模通訊中可能會變得複雜。關於對稱型金鑰總結如下：

  • 優點：加解密速度快，適合大量資料、演算法簡單，資源消耗低，適合大量資料的加解密的場景。
  • 缺點：金鑰的儲存和分發困難：無法在不可信的網路上進行分發，存在 “先有雞，還是先有蛋” 的問題。

非對稱型金鑰

非對稱加密

非對稱型金鑰加密，也稱為公鑰加密或雙金鑰加密，是一種使用兩個不同金鑰的加密方法：一個用於加密（稱為公鑰），另一個用於解密（稱為私鑰）。公鑰可以公開分享，而私鑰則必須保密。

非對稱加密的基本原理是：

  1. 金鑰生成：首先生成一對金鑰，包括一個公鑰和一個私鑰。這兩個金鑰是數學上相關的，但即使知道了公鑰，也無法輕易推匯出私鑰。

  2. 加密：當 A 想要向 B 傳送加密資訊時，A 會使用 B 的公鑰來加密資訊。這樣，只有擁有相應私鑰的 B 才能解密這條資訊。

  3. 解密：B 收到加密資訊後，使用自己的私鑰來解密，恢復原始資訊。

非對稱加密的關鍵特性是公鑰可以公開，而私鑰必須保密。這使得非對稱加密在某些應用場景中非常有用，但非對稱加密的主要缺點是計算複雜，消耗資源，速度慢等，因此它通常與對稱加密結合使用：非對稱加密用於安全地交換對稱金鑰，然後使用對稱金鑰進行實際的資料加密，以提高效率。使用非對稱型金鑰主要解決兩個不信任個體在不安全通訊環境下的資訊傳輸問題，解決資訊在公開網路中傳輸的問題，既然被截獲也不會受到影響。關於非對稱型金鑰總結如下：

  • 優點：使用金鑰對解決金鑰分發的問題，可以在公開網路中安全傳輸資訊
  • 缺點：速度慢，不適合對大量資料進行加密，計算資源消耗高，擁有長度的限制多長的金鑰只能加密多長的明文。

因此，對稱金鑰和非對稱金鑰的區分是為了滿足不同的安全需求、提高效率、簡化金鑰管理，並適應不同的通訊場景。單獨依靠某一種演算法（對稱加密、非對稱加密）既做不了加密，也做不了簽名。在實際應用中，對稱加密和非對稱加密往往是結合使用的。已混合加密方式來保護通道安全。

具體做法：

  1. 使用非對稱加密方式，協商一個金鑰（少量資訊）給通訊的另一方
  2. 雙方基於共同的金鑰進行對稱加密傳輸大量的資訊

混合使用對稱和非對稱加密方法來傳輸資訊，這樣可以同時利用兩種加密方式的優勢，也稱為現代密碼學套件。資訊傳輸的終極解決方案 HTTPS 就是基於該方式實現的。

證書

在現實生活中，我們要和一個未曾謀面的人建立信任，通常有兩種方式：

  1. 基於共同的私密資訊：對方打電話來說是我的小學同學，他能說出我們小學還有同學的名字，做過的一些糗事，那麼我就會信任他
  2. 基於許可權的公證人：對方說他是警察，需要我配合辦案，如果他能提供證件和警員編號，那麼我們也會信任他，並且進行配合

在網路世界裡面，我們不能認為兩臺計算機是相互認識並且存在共同的私密資訊的，所以解決信任問題只有基於第二種 基於許可權的公證人 的方式。

CA 認證中心

CA 認證中心是負責給計算機的服務端頒發數字證書（Certificate）的機構，類似於上面例子中給警察頒發證件的權威機構類似。當客戶端訪問服務端時，會檢查服務端的證書是有效，確認無誤後才會建立安全連結。

安全連結標識

服務端的 PKI 證書是遵循 X.509 標準，證書包含了用於 SSL/TLS 通訊的資訊，具體如下：

數字證書
  1. 版本：指出該證書使用了哪種版本的 X.509 標準（版本 1、版本 2 或是版本 3）
  2. 序列號：由 CA 分配的證書唯一的識別符號。
  3. 證書籤名演算法：說明數字證書所使用的簽名演算法。
  4. 發行者：證書頒發機構可識別名稱
  5. 有效期：證書的有效期，包括開始和結束日期。
  6. 主題：證書持有者的名稱，通常是域名，全網唯一。
  7. 使用者公鑰資訊：由 CA 中心頒發給證書持有人的公鑰和公鑰演算法資訊。
  8. 擴充套件屬性：一些後期用於擴充套件的其他屬性。

安全傳輸協議

前面介紹的繁瑣的金鑰和證書等機制，最終都是為了安全傳輸所準備的。如何將複雜的技術無感知的應用在所有人都使用的網路通訊中，成為工程師要面對的挑戰之一，SSL/TLS 技術也經歷的漫長時間和摸索，早在 1994 年就開始嘗試。以下是 SSL/TLS 技術的簡要發展歷：

  1. 1994年：SSL 的引入 - 安全套接字層（SSL）是由網景公司（Netscape）開發的，目的是為了提供一種安全的網路傳輸機制來保護網上交易的隱私和完整性。
  2. 1999年：TLS 的誕生 - 傳輸層安全協議（TLS）1.0 被作為 SSL 的後續標準正式釋出，由網際網路工程任務組（IETF）進行標準化。TLS 在設計上與SSL 3.0相似，但增強了安全性並修復了 SSL 的一些缺陷。
  3. 2006年：TLS 1.1釋出 - 作為對 TLS 1.0 的改進，TLS 1.1 在安全機制上做了進一步的增強，如引入了顯式 IV 以防止密碼本重放攻擊。
  4. 2008年：TLS 1.2 釋出 - TLS 1.2 進一步增強了協議的安全性，引入了更多的加密演算法和安全特性，比如支援 SHA-256 雜湊函式。
  5. 2018年：TLS 1.3發 布 - TLS 1.3 簡化了握手過程，提高了連線的速度和安全性。它移除了一些過時的演算法和特性，使得協議更加健壯和難以被攻擊。

TLS 在傳輸之前的握手過程一共需要進行上下兩輪、共計四次通訊，透過混合使用非對稱加密交換金鑰，使用對稱加密傳輸資訊的方式保障通訊安全。如圖：

TLS 四次握手
  1. 客戶端傳送 ClientHello 訊息：客戶端以明文的方式向伺服器傳送一個 ClientHello 訊息，該訊息包括客戶端支援的 TLS 版本、加密演算法列表（密碼套件）、會話ID（用於會話恢復）和客戶端生成的隨機數。
  2. 伺服器回應 ServerHello 訊息：伺服器選擇一個共同的 TLS 版本和密碼套件，並向客戶端傳送 ServerHello 訊息。此訊息包括伺服器生成的隨機數和會話ID，
  3. 客戶端確認 Client Handshake Finished：客戶端首先會驗證證書的有效性，如果沒有問題，客戶端會根據特定演算法計算出 MasterSecret 作為後續對稱加密的私鑰，32 位隨機數，編碼改變通知，此訊息使用新的加密引數傳送，驗證握手的完整性等。
  4. 服務端確認 Server Handshake Finished：服務端向客戶端回應最後的確認通知，包括：編碼改變通知，伺服器握手結束通知等

透過四次握手，一個 TLS 安全連線建立。客戶端和服務端透過握手協商出許多資訊，例如：只有雙方才知道的隨機金鑰，傳輸過程採用的對稱加密演算法（例如 AES 128 等）、壓縮演算法等。TLS 安全連線的建立，最終實現了以下的效果：

  • 保障所有資訊都是第三方無法竊聽（加密傳輸）
  • 無法篡改（一旦篡改通訊演算法會立刻發現）
  • 無法冒充（證書驗證身份）的

這種處理方式對上層的使用者，雖然在傳輸效能上會有下降，但在功能上完全不會感知到有 TLS 的存在。建立在這層安全傳輸層之上的 HTTP 協議，就被稱為 “HTTP over SSL/TLS”，也即是大家所熟知的 HTTPS 了。

相關文章