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

概述

現代密碼學對信息的處理主要離不開以下的三種形式:

  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 了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章