綠色掛鎖揭秘：SSL 握手是如何工作的？

每天在安全瀏覽網頁時，您會想到瀏覽器中網站 URL 地址附近著名的綠色掛鎖和 HTTPS 版本的數據傳輸協議。 在本文中，我們將了解HTTPS 為何真正安全，以及如何保護通信免受第三方竊聽。

首先，我們將簡要介紹兩個基本的加密概念：數字簽名和加密，我們將深入了解一個稱為SSL 握手的過程，該過程在客戶端和服務器開始交換通信之前執行，用於建立安全的加密上下文。 我們將通過一個稱為客戶端證書身份驗證的可選步驟來完成有關如何進一步提高安全性的信息。

公鑰密碼學 101：密鑰對

認識 Alice 和 Bob，這兩個人決定使用加密方法安全地交換他們的私人消息。 他們必鬚麵對的第一個選擇是在兩種不同的加密類型之間：對稱和非對稱密鑰加密（也稱為公鑰加密）。

但是等等，這些鍵是什麼？ 基本上，我們可以簡化為一個鍵是一個隨機的字符序列。 我們可以使用這個序列對消息進行轉換（執行某種加密操作）——我們很快就會深入研究。

對稱密鑰密碼學

使用對稱密鑰加密時，發送者生成一個密鑰，然後為接收者復制它。 發送者保存原始密鑰，並將副本傳遞給接收者。 相同的密鑰用於通信兩端的加密操作。

對稱密鑰加密的主要優點和缺點是什麼？

非對稱密鑰加密

當使用非對稱密鑰加密時，發送者和接收者都會生成一個密鑰對——一個公鑰和一個私鑰。 這些密鑰在數學上相互耦合，以在各種加密操作中協同工作。 發送者和接收者都安全地保存了他們的私鑰，但他們可以在沒有特殊預防措施的情況下交換公鑰。 他們甚至可以使用一種“公鑰黃頁”——一個公鑰服務器來發送他們的公鑰以供任何人訪問。

非對稱密鑰加密的優缺點是什麼？

由於非對稱加密設置更安全，Alice 和 Bob 決定採用它！ 現在他們可以利用這一點並開始考慮確保通信的安全性和完整性。

公鑰密碼學 101：加密

當 Alice 向 Bob 發送消息時，她想確保沒有其他人可以看到內容是什麼。 她決定加密消息。 為此，Alice 必須首先從密鑰服務器或通過通信通道直接從 Bob 獲得 Bob 的公鑰。 一旦 Alice 獲得了密鑰，她就可以使用 Bob 的公鑰對她想要發送的消息進行加密操作。

一般來說，在這個過程中，消息被加密算法（又名密碼）以塊（最常見）的形式獲取，並且在消息和密鑰之間執行一些位操作，產生一個輸出，即加密消息（又名密文） . 當 Bob 得到加密消息時，他是唯一可以用他的私鑰解密它的人。

筆記：

• 消息加密——發件人使用收件人公鑰加密消息
• 消息解密——接收者用他們的私鑰解密消息

公鑰密碼學 101：簽名

除了防止消息內容被洩露之外，能夠確認發件人的身份並驗證消息是否未被更改同樣重要。 正是出於這兩個原因，才使用數字簽名（附加到消息的單獨對象）。

Alice 首先使用散列算法開發消息散列來生成她的簽名。 散列是在消息上計算單向數學函數，產生更短的固定值輸出——不同的輸入不同。 然後她使用她的私鑰對生成的哈希進行加密（簽名）。

接下來，當 Bob 收到消息和簽名時，他可以首先使用 Alice 的公鑰解密簽名。 當成功時，他知道簽名確實是由 Alice 生成的（否則，用她的公鑰解密會失敗）。

其次，Bob 可以獲取消息並使用 Alice 之前使用的相同算法對其進行散列，並確認他的消息散列與 Alice 生成的散列相同。 當哈希匹配時，他知道消息沒有被篡改。

筆記：

• 生成簽名——發送者用他的私鑰加密（簽名）消息哈希並創建簽名
• 驗證簽名——接收者首先從簽名中解密消息散列並檢查他計算的散列是否與簽名中的散列匹配
• 加密和簽名可以分開使用，但為了最高的安全性，它們通常結合使用。 因此，您可以遇到的大多數加密函數稱為encryptSignMessage() 、 decryptVerifyMessage()等。

我希望你沒有跟上愛麗絲和鮑勃的故事。 讓我再次說明整個流程，以確保一切都清楚並總結。

1. 愛麗絲想給鮑勃發消息
2. Alice 獲取她的私鑰並生成簽名
3. Alice 獲取 Bob 的公鑰並加密消息
4. Alice 將消息發送給 Bob
5. Bob 獲取 Alice 的公鑰並驗證簽名
6. Bob 使用他的私鑰解密消息

好了，理論就夠了。 現在讓我們看看所有這些是如何在 HTTPS 中使用的！

SSL 握手

請打個招呼

當客戶端啟動與服務器的連接時，首先要進行適當的介紹，以便為其餘的通信建立加密上下文。 這可以在 HTTPS CONNECT 步驟中完成，在解析標頭和請求正文之前。 這一切都始於客戶端發送客戶端問候消息。

最重要的是，該消息包含客戶端理解的加密算法和一些附加材料，如支持的壓縮算法、協議版本、會話 ID 等。由於服務器喜歡禮貌，它還以服務器 hello 消息進行響應，其中最值得注意的是包含帶有服務器公鑰的服務器證書（是的，該過程基於公鑰加密 - 與 Alice 和 Bob 選擇的方法相同）。

證書頒發機構

現在是時候在舞台上歡迎我們的下一位客人了：證書頒發機構(CA)。 這個名字聽起來很嚴肅——但它只是一個擁有大量街頭信用的第三方實體，在全球範圍內基本上被認為是值得信賴的。 這樣的實體可以驗證服務器的身份並將他們的數字簽名與服務器證書一起放置（類似於 Alice 向 Bob 發送消息時）。

證書驗證

現在讓我們最終考慮瀏覽器 URL 地址旁邊的標題綠色掛鎖。

每個 Web 客戶端都有一個捆綁的知名且受信任的證書頒發機構的公鑰列表。 你可能還記得，在文章的開頭，我提到簽名是使用發送者的私鑰生成的，並且可以使用發送者的公鑰進行驗證。 好吧，這正是客戶所做的。 它遍歷捆綁的受信任 CA 列表並檢查服務器證書的簽名是否屬於受信任的 CA 之一。 如果是，它就會接受證書——這就是掛鎖變綠的時刻。

但這只是第一步，與安全無關。 任何人都可以復制任何公鑰證書，將其放在服務器上並將其呈現給連接的客戶端，對嗎？

客戶端驗證服務器證書後，會創建一個對稱密鑰來加密通信。 但是，正如我在開頭提到的，對稱密鑰的問題在於它們在傳輸過程中很容易被截獲。 在這一步，客戶端和服務器沒有共同的加密上下文。 因此客戶端將對稱密鑰發送給服務器，但它首先使用服務器的公鑰對其進行加密。 然後服務器收到它並需要解密它以建立安全連接的能力。

因此，即使有人會出示被盜的公鑰證書，這也是他們失敗的一步。 綁定到服務器證書公鑰的有效私鑰對於解密對稱密鑰至關重要。 當然，這對於合法服務器來說不是問題，因為它安全地保存了私鑰。 它可用於解密對稱密鑰並加密進一步的通信。

因此，總而言之， SSL 握手是一個同時使用對稱和非對稱加密類型的過程。 首先，非對稱密鑰對啟動連接並為對稱密鑰的傳輸提供安全的方式。 正如我們在開始時指出的那樣，對稱加密操作更快，因此在設置後將其用於整個通信是有益的。 此外，一旦建立了安全連接，它就會被重複使用直到過期，因此在每個客戶端請求之前不會完成非對稱密鑰設置。

還值得一提的是，在現實生活中，證書不是由最著名的可信 CA （稱為根）直接簽名的。 儘管如此，根 CA 簽署中間證書，然後最終簽署服務器證書 - 從而創建證書鏈，連接客戶端檢查該證書直到滿足有效簽名。 它當然提供了更好的安全性——當其中一個中間 CA 被破壞時，它影響的人更少。

客戶端證書驗證

現在，我們可以簡要提及一個可選步驟，因為我們擁有理解它所需的所有知識。 可以將服務器配置為在建立安全連接後請求和驗證客戶端證書以實現額外的安全性。

以同樣的方式工作——但這一次，客戶端發送他們的證書，服務器通過他們的受信任的證書頒發機構列表並對其進行驗證。 值得一提的是，服務器在開發者的控制之下（與客戶端相反，即網絡瀏覽器或移動操作系統），因此後端開發者可以輕鬆地修改受信任證書列表。

公司網絡通常使用這種機制。 最常見的是，客戶端證書由安裝在員工設備上的設備管理系統生成，並使用公司生成的根證書進行簽名。 相同的證書也被添加到後端環境中。 這樣，企業後端可以在客戶端連接時輕鬆驗證證書。

讓我們瀏覽我們的後端解決方案

閱讀更多

現在，總結一下，讓我們看一下整個流程的圖表：

概括

你已經到了文章的結尾！ 希望您已經了解HTTPS 中加密設置的實現機制以及簽名和加密過程的應用方法。

既然您知道事情是如何運作的，那麼您當然應該對數據加密更有信心。 不過，重要的是要記住，瀏覽器中的綠色掛鎖還不能保證安全。 在安全敏感的上下文中，您還應該仔細檢查證書。 正如他們所說，預先警告就是預先武裝！