HTTPS基本原理了解一下

摘要： 昨天順手把站點上了HTTPS，但是為什麼要上HTTPS，不能因為你瀏覽器給我顯示‘安全’，我就認為他是安全的，還是要知根知底，不能知其然而不知其所以然，因此抽空了解一下。 本文所涉及的加密演算法原理不做詳解，具體可Google 先來了解下相關的基本術語 對稱加密 symmetr...

昨天順手把站點上了HTTPS，但是為什麼要上HTTPS，不能因為你瀏覽器給我顯示‘安全’，我就認為他是安全的，還是要知根知底，不能知其然而不知其所以然，因此抽空了解一下。

本文所涉及的加密演算法原理不做詳解，具體可Google

先來了解下相關的基本術語

對稱加密

symmetric encryption

對稱加密所指的是加密和解密使用的相同金鑰的加密演算法，即使用金鑰S加密的資料同時用金鑰S解密。這種加密方法通常效率較高，但要求兩個交換資料的實體都要持有相同的金鑰。 對稱加密的關鍵問題是，金鑰如何傳遞。

常見的對稱加密演算法有DES、AES、RC4等。

非對稱加密

asymmetric cryptographic

非對稱加密與對稱加密相反，非對稱加密需要2個金鑰：私鑰(Private Key)和公鑰(Public Key)，這兩者總是成對出現，並且公鑰加密的資料只有私鑰能夠解密，相反，私鑰加密的內容只有公鑰能夠解密；通常公鑰是對外公開的，任何人都可以獲取到，私鑰不對外公開的。 由於公鑰是對外公開的，因此私鑰加密的內容只要獲得公鑰的任何人都可以解開 。

非對稱加密與對稱加密相比，因為其計算複雜，因此速度較慢。 非對稱加密對加密內容的長度還有限制，被加密的內容長度不能大於金鑰長度。比如現在的金鑰長度時2048位，那麼被加密的內容長度不能超過256位元組。

常見的非對稱加密演算法有RSA、Elgamal、ECC等。

非對稱加密的作用：

• 防止資訊洩露：公鑰加密的只有私鑰能解
• 身份驗證：利用數字簽名

數字摘要/訊息摘要

digital digest/message digest

數字摘要是將資料通過單向HASH函式進行計算生成一串固定長度的雜湊值，不同資料產生的雜湊值是不同的（應該說是基本不可能相同，但還是存在“碰撞的概率”，比如MD5已經證明可以快速生成相同雜湊值的不同明文），相同的資料產生的雜湊值一定是相同的，因此可以通過該雜湊值用來 保證資料防篡改和完整性（因為都會導致數字摘要發生改變） 。

常用的數字摘要演算法有MD5、SHA1、SHA256等。

訊息認證

資訊摘要只能用來解決資料的完整性問題，卻無法解決訊息的認證問題，因為HASH函式是任何人都可以使用的，第三方偽裝傳送者傳送資料和數字摘要也能通過接收者的完整檢查，卻無法識別第三方的偽裝，這是就需要訊息認證了。

訊息認證碼MAC

message authentication code

訊息認證碼是將對稱加密和數字摘要相結合起來的技術，首先將資料通過HASH函式生成數字摘要，然後將摘要通過雙方共享的金鑰加密生成訊息認證碼，最後將認證碼一起傳送給接受者。

接受者在收到訊息後，使用相同的方法生成訊息認證碼，然後與收到的訊息認證碼進行對比，如果認證碼一致，那麼資料則通過認證。

存在2個問題：

• 因為使用的是對稱加密演算法，那麼依然存在金鑰如何傳輸的問題；

• 無法防止否認，因為金鑰是雙方共享的，而接收者認為資料是對方傳遞過來的，而對方可以否認傳輸過該條資訊，並且可以生成該條資訊是由接收者自己產生的。

  

  訊息認證碼

數字簽名

Digital Signature

數字簽名是將非對稱加密和數字摘要相結合起來的技術，首先將資料通過HASH函式生成數字摘要，然後將摘要用私鑰進行加密生成數字簽名，最後將資料和數字簽名一起傳送給接收者（私鑰進行簽名，公鑰只能用來驗證簽名）。

接收者在收到訊息後，通過公鑰解密數字簽名，獲得數字摘要，然後對資料用相同的HASH函式計算數字摘要，然後與解密獲得的數字摘要進行對比，如果一樣證明資料沒有被篡改過。

1. 通過非對稱加密傳遞數字摘要，能保證摘要一定是私鑰擁有者傳送的；
2. 通過數字摘要，能夠確資料一定是沒有被篡改過的。

如何保證資料傳輸的安全

使用對稱加密

對稱加密計算簡單，速度快，是用來加密資料的好方法，但是對於網際網路上節點，要保證資料安全，就必須保證節點與節點之間通訊所使用的金鑰是不一樣的。那麼對於網際網路上的服務節點，要對其他網路節點提供服務，就需要知道對方所使用的金鑰，即伺服器需要知道網路所有客戶端所使用的金鑰；這顯然是不現實的。

使用非對稱加密

那麼既然對稱機密不行，那麼使用非對稱加密呢？私鑰由伺服器擁有，並將公鑰公開，那麼客戶端將請求用公鑰加密，傳遞給伺服器，伺服器用私鑰解密獲得請求，處理請求後，再通過私鑰加密，返回給客戶端。這樣看起來貌似還可以，但不要忘了，公鑰可是公開的，公鑰加密的固然只有擁有私鑰的伺服器才能解，但伺服器的返回資料，卻可以被任意擁有公鑰的節點解開，因此非對稱加密僅能保證 單向安全 。不僅如此，非對稱加密還有以下限制：

1. 計算複雜，速度較慢；

2. 長度有所限制，所加密的內容不能超過金鑰長度。

   

   非對稱加密傳輸

混合加密

使用對稱加密不行，使用非對稱加密也不行，那麼還有其他辦法嗎？

既然對稱加密沒辦法一開始就儲存下來，那麼在通訊的時候協商好不久行了，由客戶端告訴伺服器端對稱加密的金鑰，該金鑰通過非對稱加密來傳遞，這樣就能保證金鑰只能被服務端獲取，之後雙方在通過協商好的對稱金鑰進行通訊，既能滿足雙向通訊安全，又能提高加解密的速度，めでたしめでたし。

這就是HTTPS傳輸資料的基本原理，當然實現還要考慮各種各樣的事情。

HTTPS協議

HTTPS預設使用443埠

HTTPS的提出主要解決以下3個問題：

• 內容加密：保證資料傳輸安全
• 身份認證：確認網站的真實性
• 資料完整：防止內容被篡改

TLS/SSL

HTTP是基於TCP/IP協議的，TCP/IP在網路中傳播需要經過多個節點，而HTTP請求又是明文傳輸的，那麼有心之人輕易的可以獲得請求包和返回包，並且對其進行篡改，因此HTTP是不安全的協議。

HTTP--明文-->TCP/IP---明文--->TCP/IP--明文-->HTTP

以安全為目標，HTTPS就此產生，HTTPS是HTTP的升級版本，最上層還是HTTP協議，只不過在HTTP和TCP/IP之間加入了一層加密層TSL/SSL，TLS/SSL負責對資料進行加解密，可以看做是 HTTP over TLS/SSL 。

HTTP--明文-->TLS/SSL--密文-->TCP/IP---密文--->TCP/IP--密文-->TLS/SSL--明文-->HTTP

TLS網路協議

TLS位於應用層，連線應用層高階協議和TCP/IP協議，從而提供安全通訊。

TLS/SSL協議的版本

SSL(Secure Socket Layer)由網景公司設計，現主流使用的是SSL3.0，Google發現SSL3.0存在設計缺陷，建議禁用此協議，現目前大多數瀏覽器要麼禁止使用SSL3.0要麼會對使用SSL3.0的請求提出安全警告。

TLS(Transport Layer Security)是由IETF制定的基於SSL3.0之上的，可以看做是SSL3.0的後續版本，目前已經制定了TLS1.0、TLS1.2、TLS1.3，目前較為主流的是使用TLS1.0協議。

TLS協議握手

1. 客戶端發起連線 Client-hello

由於版本、實現、作業系統等差異的存在，通訊雙方所能夠支援的加解密演算法和TSL/SSL版本客觀上會存在不一致，那麼通訊的雙方就必須要協商好使用雙方的版本和加解密演算法；為了節省網路頻寬，雙方會在網路上進行資料壓縮傳輸，因此還會協商雙方都支援的壓縮演算法；除這些外，客戶端還會生成一個隨機數 Random_A ，用於後續金鑰的生成。

客戶端提供的資訊

Random_A

2. 伺服器端迴應 Server-hello

服務在收到客戶端的請求後，將客戶端生成的 Random_A 儲存在本地，然後從客戶端支援的加密演算法和壓縮演算法選擇合適的演算法，並且伺服器也生成一個隨機數 Random_B ，然後將選擇的演算法、隨機數、和自己的證書傳送給客戶端。

服務端提供的資訊：

Random_B

3. 客戶端迴應

如果服務端要求客戶端提供證書，那麼客戶端會先發送客戶端的證書資訊。

客戶端為驗證伺服器的證書是否合法，驗證合法之後，從證書中獲取伺服器的公鑰。客戶端生成新的隨機數 Pre-Master ，然後用伺服器的公鑰對該隨機數進行加密傳送給伺服器端。通過 Random_A 、 Random_B 、 Premaster Secret 和之前協商的對稱加密演算法，就可以得到對稱加密金鑰 enc_key=Fuc(Random_A, Random_B, Pre-Master) 。

接著傳送 change cipher spec 命令通知伺服器端表示客戶端已經準備好使用協商好的加密方式進行資料通訊。

最後客戶端計算前面傳送的所有內容的MAC傳送給伺服器端，該資訊為 finish 命令資訊。

4. 伺服器迴應客戶端

伺服器收到客戶端傳送過來的 Pre-Master 加密資料後，用私鑰進行解密，然後之前協商好的方法生成對稱加密金鑰，首先發送 change cipher spec 命令通知客戶端表示服務端已經準備好使用協商好的加密方式進行資料通訊，然後利用對稱金鑰計算前面傳送所有內容的MAC傳送給客戶端，該資訊為 finish 命令資訊。

5. 資料通訊

如果客戶端和伺服器端都能夠對Finish資訊進行正常的加解密及其驗證，證明該加密通道已經建立完成。雙方可以使用約定好的對稱加密金鑰加密HTTP請求，進行通訊。

由於 Random_A 和 Random_B 在網路中是通過明文傳播的，而握手階段是通過非對稱機密來傳遞 Pre-Master 的，因此後續通訊對稱加密金鑰的破解取決與 Pre-Master 是否能夠被破解。

為什麼要使用3個隨機數，因為通訊雙發都不相信對方的隨機數是真的隨機，而最後一個隨機數則是因為前面兩個隨機數都是明文傳播，需要一個不能被第三方獲取的加密引數。

數字證書

上面說過，傳遞第三個隨機數的時候使用了從伺服器獲取的公鑰進行加密傳輸給客戶端。既然公鑰是由伺服器提供的，萬一我們所連線的是惡意的中間人呢，此時是中間人與我們進行HTTPS通訊，中間人在於目的伺服器進行HTTPS通訊，那資料就暴露給了中間人眼中了，因此直接使用來自對方的公鑰是不行，我們還需要驗證該公鑰的合法性。

此時，就需要有一個值得信賴的第三方權威機構(Certificate Authority)來告訴我們該伺服器資訊是可以信任的，而這個方式就是通過第三方機構頒給服務的數字證書來證明，權威第三方機構頒發的證書成為 CA證書 。

證書的主要組成

• 頒發證書的機構名稱
• 證書持有者的公鑰
• 證書使用的HASH演算法
• 證書內容的數字簽名

由證書頒發方的私鑰加密計算證書內容訊息摘要得出，使得證書內容無法被偽造和篡改。

驗證證書的有效性

一般瀏覽器都會內建大多數主流權威CA的 根證書 ，所謂根證書及其有效性不需要驗證，雖然它也是一份普通的數字證書。

驗證的過程：

1. 利用證書使用的HASH演算法計算出證書內容的訊息摘要；
2. 使用根證書的公鑰解密證書內容的數字簽名得到證書提供的訊息摘要；
3. 比較1和2的訊息摘要是否一致，如一致，表示驗證通過，該證書可信任，其公鑰是由伺服器提供的。

只要證書頒發方是權威的，並且生成證書數字簽名的私鑰只有CA擁有，那麼驗證成功的數字證書是不可能被偽造的，即是可信任的。即使中間人拿到了數字證書，也無法冒充伺服器，因為他沒有數字證書中公鑰對應的私鑰，無法得到 Pre-Master ，從而無法建立連線。

通過引入權威的第三方可以保證HTTPS客戶端和伺服器的通訊是安全可信任的。

自簽發證書與雙向認證

有時候，不希望使用第三方證書，想自己簽發證書，那麼就需要自己手動生成跟證書和CA證書，並將根證書安裝到對方的系統中，對方就可以對自己進行HTTPS請求，如果對方也自簽字發證書，並將證書安裝我方系統，那麼雙方就可以進行HTTPS雙向認證。

總結

本篇只講解了HTTPS的基本原理，具體的實現還需要看RFC，因為本人不是安全方向的，點到即止即可。總的來說，上了HTTPS可以保證雙方通訊的安全，國內外的大型網站大部分已經切換到HTTPS，沒切換的也在切換的路上了，這是未來的趨勢。

參考

1. ofollow,noindex">詳解https是如何確保安全的？
2. 圖解SSL/TLS協議
3. SSL/TLS原理詳解
4. HTTPS那些事兒(二)-例項分析
5. HTTPS科普掃盲帖
6. OpenSSL 與 SSL 數字證書概念貼
7. HTTPS協議、TLS協議、證書認證過程解析
8. HTTPS工作原理