[Web] SSL/TLS和Https完整流程圖

SSL（Secure Sockets Layer）和 TLS（Transport Layer Security）是加密協議，用於在互聯網上的通信中提供安全性和數據完整性。這些協議保護互聯網用戶的隱私，防止數據在傳輸過程中被竊聽和篡改。

SSL (Secure Sockets Layer)

SSL是最早的用於加密互聯網通信的協議，由 Netscape 在 1990 年代中期開發。SSL 協議主要用於保護網絡之間的數據傳輸，最常見的用途是在網頁伺服器和瀏覽器之間建立安全連接，即通常所說的 HTTPS。SSL 經歷了幾個版本的迭代，直到 SSL 3.0。

TLS (Transport Layer Security)

TLS 是 SSL 的繼承者和現代版本，由互聯網工程任務組（IETF）開發。TLS 的目的是改進並加強安全性，它從 SSL 3.0 接手並發布了多個版本，包括 TLS 1.0、TLS 1.1、TLS 1.2 和最新的 TLS 1.3。TLS 協議在許多方面與 SSL 相似，但包括了更多的安全和效能改進。

目的和主要內容

SSL和TLS的主要目的是提供一種方式來加密數據，使得數據在從一端傳輸到另一端的過程中能夠保持機密和完整。這主要通過以下幾個關鍵特性實現：

加密：使用對稱加密來保護數據的機密性，這意味著只有通信雙方才能解讀信息。
身份驗證：使用公鑰基礎設施（PKI）中的證書和非對稱加密來驗證通信方的身份。
數據完整性：使用消息摘要技術（如 HMAC）來檢查數據在傳輸過程中是否被篡改。

這些協議是許多安全應用的基礎，包括網絡瀏覽、電子郵件、即時通訊和語音通話服務。通过这样的技术，确保了用户在使用这些服务时的通信安全和隐私保护。

以下說明Https完整流程圖:

步驟 1: 客戶端Hello（ClientHello）
核心驗證： 無
目的： 初始化通信，客戶端宣告其支持的最大 TLS 版本、提供的加密套件列表，並發送客戶端隨機數（Client Random，CR）給伺服器端，CR 在後續生成會話密鑰中扮演重要角色。
狀態: 伺服器取端得key數量: CR，客戶端取得key數量: CR

步驟 2: 伺服器Hello並提供證書（ServerHello）
核心驗證： 無
目的： 伺服器選擇和確認使用的加密套件和 TLS 版本，並發送伺服器隨機數（Server Random，SR），以及由信任的 CA 簽發 SSL/ TLS 憑證。SR 同樣用於生成會話密鑰。
狀態: 伺服器取端得key數量: CR, SR，客戶端取得key數量: CR, SR

步驟 3: 客戶端驗證伺服器憑證
核心驗證： 客戶端驗證伺服器憑證的有效性和信任度。
目的： 客戶端需要驗證伺服器回傳憑證的有效性（是否在有效期內、是否由信任的 CA 簽發、是否未被撤銷），並確認憑證中的公鑰確實屬於聲稱的服務器（例如，檢查憑證中的域名與正在訪問的域名相匹配）。
狀態: 伺服器取端得key數量: CR, SR，客戶端取得key數量: CR, SR

步驟 4: 客戶端交換和驗證
核心驗證： 使用伺服器的公鑰加密信息。
目的： 客戶端生成一個預主密鑰（Pre-Master Secret，PMS），使用伺服器的公鑰進行加密，然後發送給伺服器。這確保只有擁有對應私鑰的伺服器能夠解密並使用這個密鑰。
狀態: 伺服器取端得key數量: CR, SR，客戶端取得key數量: CR, SR, PMS

步驟 5: 伺服器端解密取得預主密鑰
核心驗證： 使用伺服器的私鑰取得預主密鑰。
目的： 使用伺服器的私鑰取得預主密鑰（Pre-Master Secret，PMS）。
狀態: 伺服器取端得key數量: CR, SR, PMS，客戶端取得key數量: CR, SR, PMS => 此時雙方都集齊三大key了！！！

步驟 6: 生成會話密鑰
核心驗證： 確認密鑰協商的安全性。
目的： 客戶端和伺服器使用CR, SR, PMS共同生成會話密鑰（Session Keys），這些密鑰用於加密和解密傳輸的數據。

步驟 7: 完成握手
核心驗證： 驗證會話的完整性。
目的： 客戶端和伺服器交換 Finished 消息，這些消息使用協商的密鑰加密，以確保整個握手過程沒有被篡改。

口語化說明，客戶端是小明，伺服器端是王老闆，小明要跟王老闆進行私人對話，小明已經:

前提，王老闆是公開的店家，小明已經提前取得王老闆的公開營業證明。

小明先打招呼，並告訴王老闆要進行的私人對話規則，並發送一組小明的隨機數。

王老闆回應小明，告訴小明他同意私人對話規則，並把一組王老闆的隨機數、營業證明、公開鑰匙發送給小明。

小明檢查王老闆的營業證明，跟公開營業證明比對，確認王老闆身份證是真的。

小明先生成一個用於私人對話的隨機數，並使用王老闆的公開鑰匙加密，把加密的隨機數發送給王老闆。

王老闆使用自己的私人鑰匙解密小明的加密的隨機數，取得私人對話的隨機數。

小明和王老闆使用 "小明的隨機數" + "王老闆的隨機數" + "私人對話的隨機數"，共同生成一組私人對話密鑰。

終於，小明和王老闆開始私人對話，每次的內容都使用私人對話密鑰加解密，以確認私人對話的安全性、完整性。

總結、補充:
１. 簡述整體流程的目的:
在雙方互相規則確認、驗證身分的過程，雙方都取得三個同樣ｋｅｙ，並把三個ｋｅｙ組成同一個對話密鑰並開始對話，對話時使用對話密鑰加解密雙方的內容，完成安全、完整的對話。

２. 驗證核心有兩個:
　１. 步驟 3: 客戶端驗證伺服器憑證，確保伺服器的身份和憑證的有效性。
　２. 步驟 4、步驟 5: 對一個隨機數，Client端公鑰加密、Server端私鑰解密，確保隨機數不洩漏。
　３. 步驟 6: 雙方對話，透過同一個對話密鑰，加解密雙方的內容。

３. 此流程涉及兩種加密方式對稱加密和非對稱加密，說明如下:

公鑰和私鑰（非對稱加密密鑰）
生成方式：公鑰和私鑰作為一對生成，通常採用非對稱加密算法如 RSA、ECC（橢圓曲線密碼學）等。在這對密鑰中，公鑰可以公開分享，而私鑰必須嚴格保密。
用途：在 SSL/ TLS 握手中，公鑰用於加密信息（例如預主密鑰），只有持有對應私鑰的伺服器才能解密這些信息。這樣確保了信息在傳輸過程中的安全。
長期性：這對密鑰通常在證書的有效期內持續使用，不會頻繁更換。
會話密鑰（對稱加密密鑰）
生成方式：會話密鑰在 SSL/ TLS 握手過程中由客戶端和伺服器共同協商生成，通常基於預主密鑰（Pre - Master Secret）和雙方各自提供的隨機數（客戶端隨機數和伺服器隨機數）。會話密鑰的生成採用特定的密鑰導出算法。
用途：一旦握手完成，會話密鑰被用於加密和解密雙方之間傳輸的數據。這意味著所有通過該連接傳輸的信息都將使用這些對稱密鑰進行加密和解密，確保數據的機密性和完整性。
短期性：會話密鑰僅在一個會話中使用，且每次新會話都會生成新的會話密鑰。這增強了安全性，即使一把密鑰被破解，也只會影響該會話的數據。