經得住拷問的 HTTPS 原理解析

此文涵蓋的大致內容：

HTTPS 是在 HTTP 和 TCP 之間建立了一個安全層，HTTP 與 TCP 通信的時候，必須先進過一個安全層，對數據包進行加密，然後將加密後的數據包傳送給 TCP，相應的 TCP 必須將數據包解密，才能傳給上面的 HTTP。

一、基本概念及理解

TLS/SSL 的功能實現主要依賴於三類基本算法

散列函數 、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

非對稱加密是實現身份認證和密鑰協商；

對稱加密是對信息進行加密；

image.png

SSL 和 TLS 的區別？

SSL 和 TLS 都是加密協議，有網絡請求的地方就可以使用這兩種協議在傳輸層進行加密，確保數據傳輸的安全，SSL是TLS的前身，網景在 1995 年發佈了直接發佈了 SSL 2.0 版本，1.0 版本沒有對外發布。由於漏洞的原因，版本 2.0 也只是曇花一現，網景在 1996 年就發佈了 SSL3.0。隨後在 1999 年的時候，基於 SSL3.0 版本，網景發佈了 TLS1.0 版本 (雖然 TLS1.0 在 SSL3.0 基礎上的改動不太大，但是這些改動都是非常重要的)。

我們現在應該使用TLS協議，因爲在 2011 年和 2015 年的時候 SSL2.0 和 SSL3.0 就已經分別被棄用了，而且由於漏洞的緣故，如果你的服務器配置了 SSL 的協議，還得手動將他們禁用掉。所以我們只給服務器配置 TLS 協議就好了，有的服務對 TLS 版本有要求，你可以在 SSL Server Test 查看服務器的證書及協議等配置。

現在 TLS 主流版本是 1.2。

SSL/TLS 協議和證書的關係

爲保證網絡安全，我們需要給服務器頒發證書，這個證書可以自己生成，但是自己頒發證書是不安全的，可以被別人僞造，所以我們一般都是在第三方認證機構購買證書 。那麼問題來了，證書到底和協議是否有關聯，我們是否需要區分 SSL 證書和 TLS 證書呢？答案是否定的，證書不依賴協議，和協議沒有太大關聯，我們也不需要去糾結是使用SSL證書和TLS證書，協議由服務器配置決定，證書是配合協議一塊使用的。

私鑰、公鑰、對稱密鑰的區別？分別是什麼？

對稱密鑰只有一個, 可以是字符串, 也可以是數字, 對應的加密方法是對稱加密。

公鑰和私鑰成對出現. 公開的密鑰叫公鑰，只有自己知道的叫私鑰

“

舉個例子:

A,B 雙方準備進行系統間的通信，基於安全的考慮，採用數據加密通信。這時候，A 有自己的公私鑰，分別是 A 公和 A 私，B 也有自己的公私鑰，分別是 B 公和 B 私。通信前，雙方需要交換公鑰，這時候，A 手上的密鑰有: A 私和 B 公，B 手上的密鑰有: B 私和 A 公

通信時，A 使用 B 公進行敏感信息的加密，使用 A 私簽名。B 收到信息後，使用 B 私進行敏感信息解密，使用 A 公進行驗籤。反之亦然。

從上面可以總結:

  1. 公鑰和私鑰成對出現. 公開的密鑰叫公鑰，只有自己知道的叫私鑰    2. 公鑰用於敏感信息的加密, 私鑰用於簽名. 所以公鑰的作用是保證數據安全, 私鑰的作用的標記信息的發送方.

  2. 用公鑰加密的數據只有對應的私鑰可以解密, 用私鑰簽名只有對應的公鑰可以驗籤.

  3. 用公私鑰加解密的方式叫作非對稱加密.

  4. 其實通信雙方使用同一對公私鑰也是可以的.

對稱加密

這種方式加密和解密同用一個密鑰。加密和解密都會用到密鑰。以對稱加密方式加密時必須將密鑰也發給對方。

Q1：許許多多的客戶端，不可能都用同一祕鑰進行信息加密，該怎麼辦呢？

解決辦法：一個客戶端使用一個密鑰進行加密

Q2：既然不同的客戶端使用不同的密鑰，那麼對稱加密的密鑰如何傳輸？

解決辦法：只能是「一端生成一個祕鑰，然後通過 HTTP 傳輸給另一端」

Q3：這個傳輸密鑰的過程，又如何保證加密？「如果被中間人攔截，密鑰也會被獲取,」 那麼你會說對密鑰再進行加密，那又怎麼保存對密鑰加密的過程，是加密的過程？

解決辦法：非對稱加密

爲什麼使用非對稱加密

以對稱加密方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，如果通信被監聽那麼密鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰，所以使用非對稱加密。

非對稱加密

採用的算法是 RSA、ECC、DH 等

加密使用一對非對稱的密鑰。一把叫做私有密鑰，另一把叫做公開密鑰。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發佈，任何人都可以獲得。

具體做法

發送密文的一方使用公鑰進行加密處理 “密鑰”，對方收到被加密的信息後，再使用自己的私有密鑰進行解密。這樣可以確保交換的密鑰是安全的前提下，之後使用對稱加密方式進行通信交換報文。利用這種方式，不需要發送用來解密的私有密鑰，也不必擔心密鑰被攻擊者竊聽而盜走。

非對稱加密，有以下特點：

非對稱加密，有以下缺點：

對稱加密和非對稱祕鑰的區別：

對稱加密 + 非對稱加密（HTTPS 採用這種方式）

HTTPS 將對稱加密與非對稱加密結合起來，充分利用兩者各自的優勢。在交換密鑰環節使用非對稱加密方式，之後的建立通信交換報文階段則使用對稱加密方式。

具體做法是：發送密文的一方使用公鑰進行加密處理 “密鑰”，對方收到被加密的信息後，再使用自己的私有密鑰進行解密。這樣可以確保交換的密鑰是安全的前提下，之後使用對稱加密方式進行通信交換報文。所以，HTTPS 採用對稱加密和非對稱加密兩者並用的混合加密機制。

CA 認證和第三方認證有什麼區別

第三方認證是指與交易雙方沒有切實的利益關係並被國家認可授權的有資歷審覈認證的單位，包括很多如，CA 認證、CE 認證、QA/QC 認證等等。拿 CE 認證來說，產品要想在歐盟市場上自由流通，就必須經國 CE 認證，加貼 “CE” 標誌，以表明產品符合歐盟《技術協調與標準化新方法》指令的基本要求，這是歐盟法律對產品提出的一種強制性要求。

CA認證是CA中心進行的認證。CA（Certificate Authority），稱爲電子商務認證中心，是負責發放和管理數字證書的權威機構，並作爲電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。CA 認證是第三方認證的一種，應用於電子商務方面。

附：我覺得第三方認證也可以叫做第三方數字證書認證

二、數字簽名 + 第三方認證

數據無法被解密，但可能被篡改，解決報文可能遭篡改問題 —— 比對數字簽名

網絡傳輸過程中需要經過很多中間節點，雖然數據無法被解密，但可能被篡改，那如何校驗數據的完整性呢？那就是校驗數字簽名。

先普及摘要的含義：對需要傳輸的文本，做一個 HASH 計算（SHA1，SHA2）

數字簽名如何生成

“

一段文本 ----hash 函數 ----》 消息摘要 ---- 私鑰加密 ----》 數字簽名

將一段文本先用 Hash 函數生成消息摘要，然後用發送者的私鑰加密生成數字簽名，與原文一起傳送給接收者。接下來就是接收者校驗數字簽名的流程了。

其實此處的發送者就是 Sever，接受者是 Client。

校驗（比對）數字簽名流程

收到原文和數字簽名之後，需要比對校驗。

步驟：
1. 數字簽名 ----發送者的公鑰解密----》 消息摘要1   
2. 原文  ----hash函數----》 消息摘要2   
3. 消息摘要1 與 消息摘要2 比對

如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，
否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。
複製代碼

接收者只有用發送者的公鑰才能解密被加密的摘要信息，然後用 HASH 函數對收到的原文產生一個摘要信息，與上一步得到的摘要信息對比。

“

舉個例子：假設消息傳遞在 Kobe，James 兩人之間發生。James 將消息連同數字簽名一起發送給 Kobe，Kobe 接收到消息後，通過校驗數字簽名，就可以驗證接收到的消息就是 James 發送的。當然，這個過程的前提是 Kobe 知道 James 的公鑰。問題來了，和消息本身一樣，公鑰不能在不安全的網絡中直接發送給 Kobe，或者說拿到的公鑰如何證明是 James 的？

此時就需要引入了證書頒發機構（Certificate Authority，簡稱 CA），CA 數量並不多，Kobe 客戶端內置了所有受信任 CA 的證書。CA 對 James 的公鑰（和其他信息）數字簽名後生成證書。

爲什麼是發送者的公鑰？請求公鑰的過程是數字簽名的過程還是校驗數字簽名的過程？

下面的【數字證書認證機構的業務流程】能給與答案，請繼續看。

解決通信方身份可能被僞裝的問題 —— 數字證書（第三方認證）

image.png

客戶端無法識別傳回公鑰是中間人的，還是服務器的，也就是客戶端可能拿到的公鑰是假的，這是問題的根本，我們可以通過某種規範可以讓客戶端和服務器都遵循某種約定，那就是通過「第三方認證的方式」

數字證書認證機構處於客戶端與服務器雙方都可信賴的第三方機構的立場上。

image.png

數字證書認證機構的業務流程

  1. 服務器的運營人員向第三方機構 CA 提交公鑰、組織信息、個人信息 (域名) 等信息並申請認證;

  2. CA 通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等;

  3. 如信息審覈通過，CA 會向申請者簽發認證文件 - 證書。證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名。其中籤名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，然後，採用 CA 的私鑰對信息摘要進行加密，密文即簽名; 【數字簽名生成的過程】

  4. 客戶端 Client 向服務器 Server 發出請求時，Server 返回證書文件;

  5. 客戶端 Client 讀取證書中的相關的明文信息，採用相同的散列函數計算得到信息摘要，然後，利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即服務器的公開密鑰是值得信賴的。【校驗數字簽名的過程】

  6. 客戶端還會驗證證書相關的域名信息、有效時間等信息; 客戶端會內置信任 CA 的證書信息 (包含公鑰)，如果 CA 不被信任，則找不到對應 CA 的證書，證書也會被判定非法。

如果僅僅是第三方認證，沒有數字簽名（只是對網站信息進行第三方機構私鑰加密）

第三方認證機構是一個公開的平臺，中間人可以去獲取。

數字簽名：將網站的信息，通過特定的算法加密，比如 MD5, 加密之後，再通過服務器的私鑰進行加密，形成「加密後的數字簽名」。

可能會發生以下情況

image.png

從上面我們知道，因爲沒有比對過程，所以中間人也向第三方認證機構進行申請，然後攔截後把所有的信息都替換成自己的，客戶端仍然可以解密，並且無法判斷這是服務器的還是中間人的，最後造成數據泄露

數字簽名的作用

  1. 能確定消息確實是由發送方簽名併發出來的，因爲別人假冒不了發送方的簽名。

  2. 數字簽名能確定消息的完整性, 證明數據是否未被篡改過。

Client 是如何去對比兩者數字簽名的呢？

  1. 瀏覽器會去安裝一些比較權威的第三方認證機構的公鑰，比如 VeriSign、Symantec 以及 GlobalSign 等等。

  2. 驗證數字簽名的時候，會直接從本地拿到相應的第三方的公鑰，對私鑰加密後的數字簽名進行解密得到真正的簽名。

  3. 然後客戶端利用簽名生成規則進行簽名生成，看兩個簽名是否匹配，如果匹配認證通過，不匹配則獲取證書失敗。

小結

三、HTTPS 工作流程（TLS 1.2 握手過程）

image.png

  1. Client 發起一個 HTTPS 請求，連接 443 端口。這個過程可以理解成是【請求公鑰的過程】。

  2. Server 端收到請求後，會把申請好的數字證書（也可以認爲是公鑰證書）返回給 Client。

  3. 瀏覽器安裝後會自動帶一些權威第三方機構公鑰，使用匹配的公鑰對數字簽名進行解密。根據簽名生成的規則對網站信息進行本地簽名生成，然後兩者比對【（解密後的簽名和對網站信息用 hash 函數生成的簽名比對，其實這也是數字簽名校驗的過程，上面寫的數字簽名校驗實例沒有經過 CA）】。通過比對兩者簽名，匹配則說明認證通過【（也可以說是證書合法，並且客戶端內置的 CA 是信任的）】，不匹配則獲取證書失敗。

  4. 在安全拿到服務器公鑰後，客戶端 Client 使用僞隨機數生成器隨機生成一個對稱密鑰，使用【服務器公鑰】（證書的公鑰）加密這個【對稱密鑰】，發送給 Server(服務器)。

  5. 服務器 Server 通過自己的私鑰，對信息解密，至此得到了【對稱密鑰】，此時兩者都擁有了相同的【對稱密鑰】，接下來，就可以通過該對稱密鑰對傳輸的信息加密 / 解密啦。

  6. Server 使用對稱密鑰加密 “明文內容 A”，發送給 Client。

  7. Client 使用對稱密鑰解密響應的密文，得到 “明文內容 A”。

  8. Client 再次發起 HTTPS 的請求，使用對稱密鑰加密請求的 “明文內容 B”，然後 Server 使用對稱密鑰解密密文，得到 “明文內容 B”。

請求到的公鑰的作用：

  1. 解密數字簽名（匹配的公鑰是服務器拿到的跟瀏覽器自帶的第三方機構公鑰匹配成功的公鑰）

  2. 加密 Client 使用僞隨機數隨機生成的一對稱祕鑰（這步驟開始對稱加密，把對稱祕鑰發送給 Server，這個步驟經過非對稱加密之後變成安全的了）

HTTPS 工作中啥時候是非對稱加密，啥時候是對稱加密？

Server 安全拿到對稱祕鑰之後，也就是 Client 和 Server 都擁有了相同的【對稱祕鑰】之後，開始對稱加密；認之前是非對稱加密。換句話說，在交換密鑰環節使用非對稱加密方式，之後的建立通信交換報文階段則使用對稱加密方式。

四、HTTP 與 HTTPS 的區別

五、既然 HTTPS 那麼安全可靠，那爲何不所有的 Web 網站都使用 HTTPS

  1. 首先，很多人還是會覺得 HTTPS實施有門檻，這個門檻在於需要權威 CA 頒發的 SSL 證書。從證書的選擇、購買到部署，傳統的模式下都會比較耗時耗力。

  2. 其次，HTTPS 普遍認爲性能消耗要大於 HTTP，因爲與純文本通信相比，加密通信會消耗更多的 CPU 及內存資源。如果每次通信都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。但事實並非如此，用戶可以通過性能優化、把證書部署在 SLB 或 CDN，來解決此問題。舉個實際的例子，“雙十一” 期間，全站 HTTPS 的淘寶、天貓依然保證了網站和移動端的訪問、瀏覽、交易等操作的順暢、平滑。通過測試發現，經過優化後的許多頁面性能與 HTTP 持平甚至還有小幅提升，因此 HTTPS 經過優化之後其實並不慢。

  3. 除此之外，想要節約購買證書的開銷也是原因之一。要進行 HTTPS 通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。

  4. 最後是安全意識。相比國內，國外互聯網行業的安全意識和技術應用相對成熟，HTTPS 部署趨勢是由社會、企業、政府共同去推動的。

總結

HTTPS 就是使用 SSL/TLS 協議進行加密傳輸大致流程：

客戶端拿到服務器的公鑰（是正確的），然後客戶端隨機生成一個「對稱加密的祕鑰」，使用「該公鑰」加密，傳輸給服務端，服務端再通過解密拿到該「對稱祕鑰」，後續的所有信息都通過該「對稱祕鑰」進行加密解密，完成整個 HTTPS 的流程。「第三方認證」，最重要的是「數字簽名」，避免了獲取的公鑰是中間人的。

作者：hannie76327
https://juejin.cn/post/6942671833304924197

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/atyLhnc2flGwoJpSHBoKTQ

猜你喜歡