tls加密套件

⑴ SSL握手分析及常見問題排查

        1. 當要建立一個tls加密的連接時.客戶端首先發送一個client hello消息給服務端,其中包含了一個客戶端生成的隨機數 random_1, 客戶端支持的加密套件(support ciphers), 以及支持的tls版本等信息;

        2. 服務端收到了客戶端的請求時,會從client hello消息中取出隨機數random_1, 客戶端的加密套件等信息,確定使用哪一種加密套件,以及再生成一個隨機數random_2, 並將這些信息包含在server hello消息中發送給客戶端;然後服務端還會將自己的證書信息發送給客戶端.

        3. 客戶端收到服務服務端的消息和證書後,會從中取出服務端生成的隨機數random_2,以及確定的加密套件等信息.並將服務端下發的證書拿到自己系統里的CA列表中進行驗證,驗證合法後從證書中取出服務端的公鑰, 再生成一個隨機數random_3.並用服務端的公鑰對random_3進行加密生成一個key發給服務端.

        4. 服務端收到客戶端發來的key之後,用自己的私鑰對其解密,取出隨機數random_3.

        5. 至此,客戶端和服務端都擁有了random_1, random_2, random_3三個隨機數,以及確定了相同的加密套件.現在只要根據相同的加密演算法對這三個隨機數進行加密生成一個密鑰,服務端和客戶端就擁有了這個相同的密鑰.此後的連接中,服務端和客戶端都使用這個密鑰對信息進行加密,就可以通過這種對稱加密的方式進行密文傳輸了.

        6. 我們可以發現,在服務端和客戶端交換隨機數的時候,是通過服務端向客戶端下發公鑰以非對稱加密的形式完成的.當服務端和客戶端都拿到了相同的三個隨機數後,用這三個隨機數生成了相同的密鑰,此後的通信就是通過這個密鑰加密和解密信息,實現了對稱加密傳輸.

         通常tls握手失敗都是由服務端以及服務端tls配置問題導致的.

        目前最主要的原因就是服務端的tls配置不支持ssl3.0.但是,客戶端這邊的問題也很有可能會導致的tls握手失敗.比如,像系統時間不正確,或者瀏覽器更新所至等一些常見的客戶端問題.

        大部分情況下, tls握手失敗都是由服務端問題所導致的. 其中有些問題很容易解決, 有些問題不容易解決,甚至有一些問題不值得去解決.

         * 客戶端支持tls1.0和tls1.1版本,但服務端只支持tls1.2

        上面這個例子就是tls協議不匹配.但是,在這種情況下,要修復這個問題,不應該是服務端來匹配低版本的協議,而應該是客戶端升級到tls1.2來匹配服務端較新的協議. 在目前,我們的建議是必須支持tls1.2和tls1.3協議,對於還不支持的網站必須添加上這兩個版本.

        tls/ssl並不是通過一個通過自身可以解決所有問題的演算法,而是一系列不同演算法的結合,不同的演算法用以實現不同的功能,它們結合在一起組成了tls/ssl.

        tls1.3版本的加密套件得到了進一步的完善.在這之前, 加密套件的演算法主要包含以下功能:

                * 對稱密鑰會話加密(Symmetric Session Key Encryption)

                * 非對稱公鑰加密(Asymmetric Public Key Encryption)

                * 證書簽名哈希(Signature Hashing)

                * 密鑰生成(Key Generation)

         許多原因都會導致瀏覽器判定tls證書不合法, 這時瀏覽器就會阻止tls握手連接. 在接下來的小節中, 我們會深入探討由於此類技術問題所引發的tls握手失敗問題.

               * 域名不匹配: 網站域名與證書中的不相匹配.

                * 證書鏈不正確: 證書鏈中缺少中間證書.

                * 證書過期或被撤銷: 服務端使用了不受信任, 過期, 或被撤銷的tls證書.

                * 使用自簽名證書: 使用自簽名證書或內部網路路徑混亂

        在以前,一個網站的非www域名和www域名之間存在著問題,但是後來證書頒發機構允許一個證書可以簽發多個子域名(SAN),已經幾乎解決了這個問題.處理證書域名錯誤的最好方法就是從新簽發一個新證書,或者使用通配符證書.

        SL/TLS和PKI信任模型通常依賴於根程序(Root program)，這是存儲在計算機系統上的受信任CA根證書的集合。其中一些根程序例如:

                * 火狐瀏覽器使用的Mozilla根程序.

                * 安卓系統使用的Google根程序.

                * IOS和macOS系統所使用的Apple根程序.

                * Windows系統使用的Microsoft根程序.

         CA根程序十分重要,雖然它不直接簽發證書,但證書機構會利用中間根證書來簽發終端用戶所使用的tls葉證書. 這就是證書鏈的運作方式, CA根證書被用來簽發中間根, 中間根又用來簽發其他中間根, 最終直到終端用戶的tls葉證書.

        當前,tls證書的最大有效期是2年. 因此,如果你的證書過期或者因為某些原因被注銷了,將會導致tls握手失敗的錯誤.解決方法是重新購買和安裝一份合法的證書.

        如果你的暴露在公網上的網站使用的是自簽名證書,這是不被信任的,將會導致錯誤. 要解決這個錯誤,你需要去一個受信任的CA機構重新簽署一份tls證書.

⑵ 網路（四）：應用層HTTPS

網路（一）：基礎知識
網路（二）：傳輸層TCP、UDP
網路（三）：應用層HTTP
網路（四）：應用層HTTPS

HTTPS（Hyper Text Transfer Protocol Secure），超文本傳輸安全協議，設計HTTPS的目的就是為了安全傳輸數據。HTTPS的默認埠號是443，HTTP的默認埠號是80。

HTTPS是安全的，但並非所有公司都使用了HTTPS，又或者公司某些涉及敏感數據的請求才使用了HTTPS、其它還是使用HTTP，這是因為使用HTTPS是有成本的：

HTTPS也常被稱為HTTP over SSL或HTTP over TLS，即使用了SSL的HTTP或使用了TLS的HTTP。

TLS（Transport Layer Security），傳輸層安全協議，它的前身就是SSL（Secure Socket Layer），安全套接層協議。歷史版本信息：

SSL/TLS工作在應用層和傳輸層之間，應用層的數據會使用SSL/TLS生成的密鑰加密後再傳遞給傳輸層，從而保證了數據在傳輸過程中的安全性。

HTTPS的通信過程可以分為四大階段：

接下來我們就看一下TLS是怎麼生成和傳輸對稱加密密鑰的，這個過程會有十次關鍵的握手，我們省略了一些不關心的ACK：

客戶端會給伺服器發送一個 Client Hello 消息，該消息內部包含TLS的版本——用來告訴伺服器客戶端想使用哪個版本的TLS，包含支持的加密套件——用來告訴伺服器客戶端支持哪些密鑰交換演算法以及支持哪些加密演算法、消息摘要演算法，包含一個隨機數Client Random——將來用來生成對稱加密的密鑰。

伺服器會給客戶端發送一個 Server Hello 消息，該消息內部包含TLS的版本——用來告訴客戶端伺服器想使用哪個版本的TLS，包含選擇的加密套件——用來告訴客戶端伺服器選擇了哪一套密鑰交換演算法以及哪一套加密演算法、消息摘要演算法（假設選擇了TLS_ECDHE_ECDSA_...），包含一個隨機數Server Random——將來用來生成對稱加密的密鑰。

伺服器會給客戶端發送一個 Certificate 消息—— 伺服器會把在CA認證過的證書（包含公鑰、公鑰的數字簽名等信息）發給客戶端，客戶端會用CA公鑰來驗證並獲取到公鑰，這個公鑰就是將來非對稱加密要用到的公鑰。

伺服器會給客戶端發送一個 Server Key Exchange 消息—— 對稱加密的密鑰交換演算法ECDHE_ECDSA需要一些參數，伺服器需要提供一部分、並發給客戶端，我們把伺服器提供的這部分參數稱之為Server Params。

伺服器會給客戶端發送一個 Server Hello Done 消息—— 伺服器告訴客戶端伺服器已經沒什麼協商數據需要發給客戶端了。

客戶端會給伺服器發送一個 Client Key Exchange 消息——對稱加密的密鑰交換演算法ECDHE_ECDSA需要一些參數，客戶端需要提供一部分、並發給伺服器，我們把客戶端提供的這部分參數稱之為Client Params。

客戶端會給伺服器發送一個 Change Cipher Spec 消息——客戶端告訴伺服器以後客戶端發給伺服器的數據都會用對稱加密的密鑰進行加密。

客戶端會給伺服器發送一個 Finished 消息——客戶端會把第一次TLS握手 ~ 第七次TLS握手全部的數據生成一個摘要，然後再把這個摘要用對稱加密密鑰1加密之後發送給伺服器，目的就是為了讓伺服器去解密，進而判定對稱加密密鑰1能有效加解密。

伺服器也會給客戶端發送一個 Change Cipher Spec 消息——伺服器告訴客戶端以後伺服器發給客戶端的數據也都會用對稱加密密鑰2進行加密。

伺服器會給客戶端發送一個 Finished 消息——伺服器會把第一次TLS握手 ~ 第九次TLS握手全部的數據生成一個摘要，然後再把這個摘要用對稱加密密鑰2加密之後發送給客戶端，目的就是為了讓客戶端去解密，進而判定對稱加密密鑰2能有效加解密。

⑶ 前端安全

什麼時候會跳過preflightrequest

Stored：存儲

Reflected：反射性

DOM-based：未連接伺服器

例子：

XSS防禦：

標簽白名單

轉義（HTML + JavaScript）

禁止動態修改 CSS 資源引用

特殊協議（dataURI）

減少/避免一些 DOM 操作

CSP： 只允許從我認可的地方載入資源

驗證碼

Referer：請求頭從哪個網站來的（HTTP Referer是header的一部分，當瀏覽器向web 伺服器 發送請求的時候，一般會帶上Referer，告訴伺服器我是從哪個頁面鏈接過來的，伺服器基此可以獲得一些信息用於處理。）

Anti CSRF Token：

盡量用 POST

DNS 劫持：

本地 host

設備（路由器/交換機）

DNS 伺服器

HTTP劫持：

Man-in-the-middle attack(MITA)

防禦 HTTP 劫持：

CSP

SRI

HTTPS

Browser：支持的 TLS 版本 + 加密套件，一個隨機數1

Server：選擇 TLS 版本 + 加密套件，一個隨機數2，[session id]

[Server：證書（public key）]

[Server：ServerKeyExchange]

Server：over

Browser：驗證證書，用證書中的 public key 加密新的隨機數3，生成 PreMasterSecret

Browser + Server：使用 隨機數1 + 隨機數2 + PreMasterSecret，計算出 master secret，此後，所有信息都會用 master secret 加密

Browser：之前幾步，涉及信息的 HASH + MAC，server 驗證

Server：重復 browser 剛剛做的

⑷ TLS 詳解

SSL (Secure Sockets Layer) 安全套接層，是一種安全協議，經歷了 SSL 1.0、2.0、3.0 版本後發展成了標准安全協議 - TLS (Transport Layer Security) 傳輸層安全性協議。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。

TLS 在實現上分為 記錄層 和 握手層 兩層，其中握手層又含四個子協議: 握手協議 (handshake protocol)、更改加密規范協議 (change cipher spec protocol)、應用數據協議 (application data protocol) 和警告協議 (alert protocol)

只需配置瀏覽器和伺服器相關設置開啟 TLS，即可實現 HTTPS，TLS 高度解耦，可裝可卸，與上層高級應用層協議相互協作又相互獨立。

TLS/SSL 的功能實現主要依賴於三類基本演算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密演算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

TLS 的基本工作方式是，客戶端使用非對稱加密與伺服器進行通信，實現身份驗證並協商對稱加密使用的密鑰，然後對稱加密演算法採用協商密鑰對信息以及信息摘要進行加密通信，不同的節點之間採用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。

例如，在 HTTPS 協議中，客戶端發出請求，服務端會將公鑰發給客戶端，客戶端驗證過後生成一個密鑰再用公鑰加密後發送給服務端（非對稱加密），雙方會在 TLS 握手過程中生成一個協商密鑰（對稱密鑰），成功後建立加密連接。通信過程中客戶端將請求數據用協商密鑰加密後發送，服務端也用協商密鑰解密，響應也用相同的協商密鑰。後續的通信使用對稱加密是因為對稱加解密快，而握手過程中非對稱加密可以保證加密的有效性，但是過程復雜，計算量相對來說也大。

記錄協議負責在傳輸連接上交換的所有底層消息，並且可以配置加密。每一條 TLS 記錄以一個短標頭開始。標頭包含記錄內容的類型 (或子協議)、協議版本和長度。原始消息經過分段 (或者合並)、壓縮、添加認證碼、加密轉為 TLS 記錄的數據部分。

記錄層將信息塊分割成攜帶 2^14 位元組 (16KB) 或更小塊的數據的 TLSPlaintext 記錄。

記錄協議傳輸由其他協議層提交給它的不透明數據緩沖區。如果緩沖區超過記錄的長度限制（2^14），記錄協議會將其切分成更小的片段。反過來也是可能的，屬於同一個子協議的小緩沖區也可以組合成一個單獨的記錄。

壓縮演算法將 TLSPlaintext 結構轉換為 TLSCompressed 結構。如果定義 CompressionMethod 為 null 表示不壓縮

流加密（BulkCipherAlgorithm）將 TLSCompressed.fragment 結構轉換為流 TLSCiphertext.fragment 結構

MAC 產生方法如下：

seq_num（記錄的序列號）、hash（SecurityParameters.mac_algorithm 指定的哈希演算法）

塊加密（如 RC2 或 DES），將 TLSCompressed.fragment 結構轉換為塊 TLSCiphertext.fragment 結構

padding: 添加的填充將明文長度強制為塊密碼塊長度的整數倍。填充可以是長達 255 位元組的任何長度，只要滿足 TLSCiphertext.length 是塊長度的整數倍。長度大於需要的值可以阻止基於分析交換信息長度的協議攻擊。填充數據向量中的每個 uint8 必須填入填充長度值 (即 padding_length)。

padding_length: 填充長度應該使得 GenericBlockCipher 結構的總大小是加密塊長度的倍數。合法值范圍從零到 255（含）。 該長度指定 padding_length 欄位本身除外的填充欄位的長度

加密塊的數據長度（TLSCiphertext.length）是 TLSCompressed.length，CipherSpec.hash_size 和 padding_length 的總和加一

加密和 MAC 功能將 TLSCompressed 結構轉換為 TLSCiphertext。記錄的 MAC 還包括序列號，以便可以檢測到丟失，額外或重復的消息。

記錄協議需要一種演算法，從握手協議提供的安全性參數生成密鑰、 IV 和 MAC secret.

主密鑰 (Master secret): 在連接中雙方共享的一個 48 位元組的密鑰
客戶隨機數 (client random): 由客戶端提供的 32 位元組值
伺服器隨機數 (server random): 由伺服器提供的 32 位元組值

握手是 TLS 協議中最精密復雜的部分。在這個過程中，通信雙方協商連接參數，並且完成身 份驗證。根據使用的功能的不同，整個過程通常需要交換 6~10 條消息。根據配置和支持的協議擴展的不同，交換過程可能有許多變種。在使用中經常可以觀察到以下三種流程：(1) 完整的握手， 對伺服器進行身份驗證；(2) 恢復之前的會話採用的簡短握手；(3) 對客戶端和伺服器都進行身份驗證的握手。

握手協議消息的標頭信息包含消息類型（1 位元組）和長度（3 位元組），餘下的信息則取決於消息類型：

每一個 TLS 連接都會以握手開始。如果客戶端此前並未與伺服器建立會話，那麼雙方會執行一次完整的握手流程來協商 TLS 會話。握手過程中，客戶端和伺服器將進行以下四個主要步驟:

下面介紹最常見的握手規則，一種不需要驗證客戶端身份但需要驗證伺服器身份的握手:

這條消息將客戶端的功能和首選項傳送給伺服器。

是將伺服器選擇的連接參數傳回客戶端。

這個消息的結構與 ClientHello 類似，只是每個欄位只包含一個選項，其中包含服務端的 random_S 參數 (用於後續的密鑰協商)。伺服器無需支持客戶端支持的最佳版本。如果伺服器不支持與客戶端相同的版本，可以提供某個其他版本以期待客戶端能夠接受

圖中的 Cipher Suite 是後續密鑰協商和身份驗證要用的加密套件，此處選擇的密鑰交換與簽名演算法是 ECDHE_RSA，對稱加密演算法是 AES-GCM，後面會講到這個

還有一點默認情況下 TLS 壓縮都是關閉的，因為 CRIME 攻擊會利用 TLS 壓縮恢復加密認證 cookie，實現會話劫持，而且一般配置 gzip 等內容壓縮後再壓縮 TLS 分片效益不大又額外佔用資源，所以一般都關閉 TLS 壓縮

典型的 Certificate 消息用於攜帶伺服器 X.509 證書鏈 。
伺服器必須保證它發送的證書與選擇的演算法套件一致。比方說，公鑰演算法與套件中使用的必須匹配。除此以外，一些密鑰交換演算法依賴嵌入證書的特定數據，而且要求證書必須以客戶端支持的演算法簽名。所有這些都表明伺服器需要配置多個證書（每個證書可能會配備不同的證書鏈）。

Certificate 消息是可選的，因為並非所有套件都使用身份驗證，也並非所有身份驗證方法都需要證書。更進一步說，雖然消息默認使用 X.509 證書，但是也可以攜帶其他形式的標志；一些套件就依賴 PGP 密鑰

攜帶密鑰交換需要的額外數據。ServerKeyExchange 是可選的，消息內容對於不同的協商演算法套件會存在差異。部分場景下，比如使用 RSA 演算法時，伺服器不需要發送此消息。

ServerKeyExchange 僅在伺服器證書消息（也就是上述 Certificate 消息）不包含足夠的數據以允許客戶端交換預主密鑰（premaster secret）時才由伺服器發送。

比如基於 DH 演算法的握手過程中，需要單獨發送一條 ServerKeyExchange 消息帶上 DH 參數:

表明伺服器已經將所有預計的握手消息發送完畢。在此之後，伺服器會等待客戶端發送消息。

客戶端驗證證書的合法性，如果驗證通過才會進行後續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證內容包括如下:

由 PKI 體系 的內容可知，對端發來的證書簽名是 CA 私鑰加密的，接收到證書後，先讀取證書中的相關的明文信息，採用相同的散列函數計算得到信息摘要，然後利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性；然後去查詢證書的吊銷情況等

合法性驗證通過之後，客戶端計算產生隨機數字的預主密鑰（Pre-master），並用證書公鑰加密，發送給伺服器並攜帶客戶端為密鑰交換提供的所有信息。這個消息受協商的密碼套件的影響，內容隨著不同的協商密碼套件而不同。

此時客戶端已經獲取全部的計算協商密鑰需要的信息: 兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，然後得到協商密鑰(用於之後的消息加密)

圖中使用的是 ECDHE 演算法，ClientKeyExchange 傳遞的是 DH 演算法的客戶端參數，如果使用的是 RSA 演算法則此處應該傳遞加密的預主密鑰

通知伺服器後續的通信都採用協商的通信密鑰和加密演算法進行加密通信

Finished 消息意味著握手已經完成。消息內容將加密，以便雙方可以安全地交換驗證整個握手完整性所需的數據。

這個消息包含 verify_data 欄位，它的值是握手過程中所有消息的散列值。這些消息在連接兩端都按照各自所見的順序排列，並以協商得到的主密鑰 (enc_key) 計算散列。這個過程是通過一個偽隨機函數（pseudorandom function，PRF）來完成的，這個函數可以生成任意數量的偽隨機數據。
兩端的計算方法一致，但會使用不同的標簽（finished_label）：客戶端使用 client finished，而伺服器則使用 server finished。

因為 Finished 消息是加密的，並且它們的完整性由協商 MAC 演算法保證，所以主動網路攻擊者不能改變握手消息並對 vertify_data 的值造假。在 TLS 1.2 版本中，Finished 消息的長度默認是 12 位元組（96 位），並且允許密碼套件使用更長的長度。在此之前的版本，除了 SSL 3 使用 36 位元組的定長消息，其他版本都使用 12 位元組的定長消息。

伺服器用私鑰解密加密的 Pre-master 數據，基於之前交換的兩個明文隨機數 random_C 和 random_S，同樣計算得到協商密鑰: enc_key = PRF(Pre_master, "master secret", random_C + random_S) ;

同樣計算之前所有收發信息的 hash 值，然後用協商密鑰解密客戶端發送的 verify_data_C，驗證消息正確性;

服務端驗證通過之後，伺服器同樣發送 change_cipher_spec 以告知客戶端後續的通信都採用協商的密鑰與演算法進行加密通信（圖中多了一步 New Session Ticket，此為會話票證，會在會話恢復中解釋）;

伺服器也結合所有當前的通信參數信息生成一段數據 (verify_data_S) 並採用協商密鑰 session secret (enc_key) 與演算法加密並發送到客戶端;

客戶端計算所有接收信息的 hash 值，並採用協商密鑰解密 verify_data_S，驗證伺服器發送的數據和密鑰，驗證通過則握手完成;

開始使用協商密鑰與演算法進行加密通信。

HTTPS 通過 TLS 層和證書機制提供了內容加密、身份認證和數據完整性三大功能。加密過程中，需要用到非對稱密鑰交換和對稱內容加密兩大演算法。

對稱內容加密強度非常高，加解密速度也很快，只是無法安全地生成和保管密鑰。在 TLS 協議中，最後的應用數據都是經過對稱加密後傳輸的，傳輸中所使用的對稱協商密鑰(上文中的 enc_key)，則是在握手階段通過非對稱密鑰交換而來。常見的 AES-GCM、ChaCha20-Poly1305，都是對稱加密演算法。

非對稱密鑰交換能在不安全的數據通道中，產生只有通信雙方才知道的對稱加密密鑰。目前最常用的密鑰交換演算法有 RSA 和 ECDHE。

RSA 歷史悠久，支持度好，但不支持 完美前向安全 - PFS(Perfect Forward Secrecy) ；而 ECDHE 是使用了 ECC（橢圓曲線）的 DH（Diffie-Hellman）演算法，計算速度快，且支持 PFS。

在 PKI 體系 一節中說明了僅有非對稱密鑰交換還是無法抵禦 MITM 攻擊的，所以需要引入了 PKI 體系的證書來進行身份驗證，其中服務端非對稱加密產生的公鑰會放在證書中傳給客戶端。

在 RSA 密鑰交換中，瀏覽器使用證書提供的 RSA 公鑰加密相關信息，如果服務端能解密，意味著服務端擁有與公鑰對應的私鑰，同時也能算出對稱加密所需密鑰。密鑰交換和服務端認證合並在一起。

在 ECDH 密鑰交換中，服務端使用私鑰 (RSA 或 ECDSA) 對相關信息進行簽名，如果瀏覽器能用證書公鑰驗證簽名，就說明服務端確實擁有對應私鑰，從而完成了服務端認證。密鑰交換則是各自發送 DH 參數完成的，密鑰交換和服務端認證是完全分開的。

可用於 ECDHE 數字簽名的演算法主要有 RSA 和 ECDSA - 橢圓曲線數字簽名演算法 ，也就是目前密鑰交換 + 簽名有三種主流選擇:

比如我的網站使用的加密套件是 ECDHE_RSA，可以看到數字簽名演算法是 sha256 哈希加 RSA 加密，在 PKI 體系 一節中講了簽名是伺服器信息摘要的哈希值加密生成的

內置 ECDSA 公鑰的證書一般被稱之為 ECC 證書，內置 RSA 公鑰的證書就是 RSA 證書。因為 256 位 ECC Key 在安全性上等同於 3072 位 RSA Key，所以 ECC 證書體積比 RSA 證書小，而且 ECC 運算速度更快，ECDHE 密鑰交換 + ECDSA 數字簽名是目前最好的加密套件

以上內容來自本文: 開始使用 ECC 證書

關於 ECC 證書的更多細節可見文檔: ECC Cipher Suites for TLS - RFC4492

使用 RSA 進行密鑰交換的握手過程與前面說明的基本一致，只是沒有 ServerKeyExchange 消息，其中協商密鑰涉及到三個參數 (客戶端隨機數 random_C、服務端隨機數 random_S、預主密鑰 Premaster secret)，
其中前兩個隨機數和協商使用的演算法是明文的很容易獲取，最後一個 Premaster secret 會用伺服器提供的公鑰加密後傳輸給伺服器 (密鑰交換)，如果這個預主密鑰被截取並破解則協商密鑰也可以被破解。

RSA 演算法的細節見: wiki 和 RSA演算法原理（二）- 阮一峰

RSA 的演算法核心思想是利用了極大整數 因數分解 的計算復雜性

而使用 DH(Diffie-Hellman) 演算法 進行密鑰交換，雙方只要交換各自的 DH 參數(在 ServerKeyExchange 發送 Server params，在 ClientKeyExchange 發送 Client params)，不需要傳遞 Premaster secret，就可以各自算出這個預主密鑰

DH 的握手過程如下，大致過程與 RSA 類似，圖中只表達如何生成預主密鑰:

伺服器通過私鑰將客戶端隨機數 random_C，服務端隨機數 random_S，服務端 DH 參數 Server params 簽名生成 signature，然後在 ServerKeyExchange 消息中發送服務端 DH 參數和該簽名；

客戶端收到後用伺服器給的公鑰解密驗證簽名，並在 ClientKeyExchange 消息中發送客戶端 DH 參數 Client params；

服務端收到後，雙方都有這兩個參數，再各自使用這兩個參數生成預主密鑰 Premaster secret，之後的協商密鑰等步驟與 RSA 基本一致。

關於 DH 演算法如何生成預主密鑰，推薦看下 Wiki 和 Ephemeral Diffie-Hellman handshake

其核心思想是利用了 離散對數問題 的計算復雜性

演算法過程可以抽象成下圖:

雙方預先商定好了一對 P g 值 (公開的)，而 Alice 有一個私密數 a(非公開，對應一個私鑰)，Bob 有一個私密數 b(非公開，對應一個私鑰)

對於 Alice 和 Bob 來說通過對方發過來的公鑰參數和自己手中的私鑰可以得到最終相同的密鑰

而第三方最多知道 P g A B，想得到私鑰和最後的密鑰很困難，當然前提是 a b P 足夠大 (RFC3526 文檔中有幾個常用的大素數可供使用)，否則暴力破解也有可能試出答案，至於 g 一般取個較小值就可以

如下幾張圖是實際 DH 握手發送的內容:

可以看到雙方發給對方的參數中攜帶了一個公鑰值，對應上述的 A 和 B

而且實際用的加密套件是 橢圓曲線 DH 密鑰交換 (ECDH) ，利用由橢圓曲線加密建立公鑰與私鑰對可以更進一步加強 DH 的安全性，因為目前解決橢圓曲線離散對數問題要比因式分解困難的多，而且 ECC 使用的密鑰長度比 RSA 密鑰短得多(目前 RSA 密鑰需要 2048 位以上才能保證安全，而 ECC 密鑰 256 位就足夠)

關於 橢圓曲線密碼學 - ECC ，推薦看下 A Primer on Elliptic Curve Cryptography - 原文 - 譯文

盡管可以選擇對任意一端進行身份驗證，但人們幾乎都啟用了對伺服器的身份驗證。如果伺服器選擇的套件不是匿名的，那麼就需要在 Certificate 消息中跟上自己的證書。

相比之下，伺服器通過發送 CertificateRequest 消息請求對客戶端進行身份驗證。消息中列出所有可接受的客戶端證書。作為響應，客戶端發送自己的 Certificate 消息（使用與伺服器發送證書相同的格式），並附上證書。此後，客戶端發送 CertificateVerify 消息，證明自己擁有對應的私鑰。

只有已經過身份驗證的伺服器才被允許請求客戶端身份驗證。基於這個原因，這個選項也被稱為相互身份驗證（mutual authentication）。

在 ServerHello 的過程中發出，請求對客戶端進行身份驗證，並將其接受的證書的公鑰和簽名演算法傳送給客戶端。

它也可以選擇發送一份自己接受的證書頒發機構列表，這些機構都用其可分辨名稱來表示:

在 ClientKeyExchange 的過程中發出，證明自己擁有的私鑰與之前發送的客戶端證書中的公鑰匹配。消息中包含一條到這一步為止的所有握手消息的簽名：

最初的會話恢復機制是，在一次完整協商的連接斷開時，客戶端和伺服器都會將會話的安全參數保存一段時間。希望使用會話恢復的伺服器為會話指定唯一的標識，稱為會話 ID(Session ID)。伺服器在 ServerHello 消息中將會話 ID 發回客戶端。

希望恢復早先會話的客戶端將適當的 Session ID 放入 ClientHello 消息，然後提交。伺服器如果同意恢復會話，就將相同的 Session ID 放入 ServerHello 消息返回，接著使用之前協商的主密鑰生成一套新的密鑰，再切換到加密模式，發送 Finished 消息。
客戶端收到會話已恢復的消息以後，也進行相同的操作。這樣的結果是握手只需要一次網路往返。

Session ID 由伺服器端支持，協議中的標准欄位，因此基本所有伺服器都支持，伺服器端保存會話 ID 以及協商的通信信息，佔用伺服器資源較多。

用來替代伺服器會話緩存和恢復的方案是使用會話票證（Session ticket）。使用這種方式，除了所有的狀態都保存在客戶端（與 HTTP Cookie 的原理類似）之外，其消息流與伺服器會話緩存是一樣的。

其思想是伺服器取出它的所有會話數據（狀態）並進行加密 (密鑰只有伺服器知道)，再以票證的方式發回客戶端。在接下來的連接中，客戶端恢復會話時在 ClientHello 的擴展欄位 session_ticket 中攜帶加密信息將票證提交回伺服器，由伺服器檢查票證的完整性，解密其內容，再使用其中的信息恢復會話。

這種方法有可能使擴展伺服器集群更為簡單，因為如果不使用這種方式，就需要在服務集群的各個節點之間同步會話。
Session ticket 需要伺服器和客戶端都支持，屬於一個擴展欄位，佔用伺服器資源很少。

⑸ 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版本有要求，比如我最近在做的小程序開發，要求TLS版本最低2.0，所以你可以在 SSL Server Test 查看伺服器的證書及協議等配置

為保證網路安全，我們需要給伺服器頒發證書，這個證書可以自己生成，但是自己頒發證書是不安全的，可以被別人偽造，所以我們一般都是在第三方認證機構購買證書。那麼問題來了，證書到底和協議是否有關聯，我們是否需要區分SSL證書和TLS證書呢？答案是否定的，證書不依賴協議，和協議沒有太大關聯，我們也不需要去糾結是使用SSL證書和TLS證書，協議由伺服器配置決定，證書是配合協議一塊使用的。
關於證書可以參考知乎大神的回答 https://www.hu.com/question/52493697

本文參考：
https://www.globalsign.com/en/blog/ssl-vs-tls-difference/

⑹ 我們應該使用 TLS1.3 嗎

SSL（Socket Layer Security）和 TLS（Transport Layer Security） 都是屬於安全協議，主要作用是保證客戶端和服務端之間能安全通訊。SSL是較早的協議，TLS 是 SSL的替代者。

SSL 版本 1.0、2.0 和 3.0，TLS 版本 1.0、1.2 和 1.3。SSL協議和TLS1.0 由於已過時被禁用，目前TLS 1.3 是互聯網上部署最多的安全協議，它是TLS最新版本 ，它增強了過時的安全性，並增加了更多的觸控性。通過下面幾點可以有個簡單認識：

現代瀏覽器支持 TLS 1.2 和 TLS 1.3 協議，但 1.3 版本要好得多。 TLS 1.3 對早期版本進行了多項改進，最明顯的是簡化了TLS握手操作，使得握手時間變短、網站性能得以提升、改善了用戶體驗，另外支持的密碼套件更安全和簡單。

密碼套件

TLS/SSL 使用一種或多種密碼套件。 密碼套件是身份驗證、加密和消息身份驗證的演算法組合。TLS 1.2 版使用的演算法存在一些弱點和安全漏洞。在 TLS 1.3 中刪除了這些演算法：

另外一個很重要的更新是TLS1.3 支持 perfect-forward-secrecy （PFS）演算法。

向前保密 （PFS）是特定密鑰協商協議的一項功能，如果一個長周期的會話密鑰被泄露，黑客就會截獲大量數據，我們可以為每個會話生成唯一的會話密鑰，單個會話密鑰的泄露不會影響該會話之外的任何數據。

TLS在早期版本的握手期間可以使用兩種機制之一交換密鑰：靜態 RSA密鑰和 Diffie-Hellman 密鑰。 在 TLS1.3 中，RSA 以及所有靜態（非 PFS）密鑰交換已被刪除，只保留了DHE、ECDHE

可以查看網站的安全詳情來確認它是否使用"ECDHE"或"DHE"。

AES (Advanced Encryption Standard) 對稱加密，它是 高級加密 標准。早期的加密標准DES(Data Encryption Standard) 已被棄用。

AES選擇合適的 加密模式 很重要，應用比較多的兩種模式 CBC 和 GCM。

CBC 密碼分組鏈接模式

明文分塊，第一個塊使用初始化向量，後面的每個明文塊在加密前與前一個密文塊進行異或運算。

這種模式存在的問題：

CTR 計數模式

明文分塊按順序編號，通過加密"計數器"的連續值來生成下一個密鑰流塊。CTR 模式非常適合在多核處理器上運行，明文塊可以並行加密。

GCM 伽羅瓦/計數器模式

GCM = CTR + Authentication。其加密過程，明文塊是按順序編號的，然後這個塊號與初始向量 組合並使用塊密碼E加密，然後將此加密的結果與明文進行異或以生成密文。

簡單來說，GCM 是 CTR 身份驗證的組合，它更快、更安全。它將接受流水線和並行化實現，並具有最小的計算延遲，所以它的應用更加廣泛。

客戶端最低版本

客戶端最低版本

一般建議同時兼容1.2和1.3

測試是否支持 TLS 1.2

測試是否支持 TLS 1.3

⑺ 什麼是SSL/TLS解密

SSL加密是在傳輸層對網路連接進行加密，安全傳輸層協議（TLS）用於在兩個通信應用程序之間提供保密性和數據完整性。就是我們看到地址欄https://，TLS加密套件、SSL屬於數字證書，相互相成。

起初是因為HTTP在傳輸數據時使用的是明文（雖然說POST提交的數據時放在報體里看不到的，但是還是可以通過抓包工具竊取到）是不安全的，為了解決這一隱患網景公司推出了SSL安全套接字協議層，SSL是基於HTTP之下TCP之上的一個協議層，是基於HTTP標准並對TCP傳輸數據時進行加密，所以HTTPS是HTTP+SSL/TCP的簡稱。

⑻ TLS加密過程

## SSL 證書類型

**certbot**

域名驗證（domain validated, DV證書）

組織驗證（organization validated,OV 證書）：驗證組織是否正確

擴展驗證（extended validation EV證書）：顯示友好

根證書-》二級證書-》主站點

## TLS加密過程

1. 驗證身份

2. 達成安全套件共識

3. 傳遞密鑰

4. 加密通訊

HTTPS採用混合加密演算法，即共享秘鑰加密（對稱加密）和公開秘鑰加密（非對稱加密）。

通信前准備工作：

A、數字證書認證機構的公開秘鑰（CA公鑰）已事先植入到瀏覽器里；

B、數字證書認證機構用自己的私有密鑰對伺服器的公開秘鑰做數字簽名，生成公鑰證書，並頒發給伺服器。

1、client hello

握手第一步是客戶端向服務端發送 Client Hello 消息，這個消息里包含了一個客戶端生成的隨機數 Random1、客戶端支持的加密套件（Support Ciphers）和 SSL Version 等信息。

2、server hello

服務端向客戶端發送 Server Hello 消息，這個消息會從 Client Hello 傳過來的 Support Ciphers 里確定一份加密套件，這個套件決定了後續加密和生成摘要時具體使用哪些演算法，另外還會生成一份隨機數 Random2。注意，至此客戶端和服務端都擁有了兩個隨機數（Random1+ Random2），這兩個隨機數會在後續生成對稱秘鑰時用到。

3、Certificate

這一步是服務端將自己的公鑰證書下發給客戶端。

4、Server Hello Done

Server Hello Done 通知客戶端 Server Hello 過程結束。

5、Certificate Verify

客戶端收到服務端傳來的公鑰證書後，先從 CA 驗證該證書的合法性（CA公鑰去解密公鑰證書），驗證通過後取出證書中的服務端公鑰，再生成一個隨機數 Random3，再用服務端公鑰非對稱加密 Random3生成 PreMaster Key。

6、Client Key Exchange

上面客戶端根據伺服器傳來的公鑰生成了 PreMaster Key，Client Key Exchange 就是將這個 key 傳給服務端，服務端再用自己的私鑰解出這個 PreMaster Key 得到客戶端生成的 Random3。至此，客戶端和服務端都擁有 Random1 + Random2 + Random3，兩邊再根據同樣的演算法就可以生成一份秘鑰，握手結束後的應用層數據都是使用這個秘鑰進行對稱加密。

為什麼要使用三個隨機數呢？這是因為 SSL/TLS 握手過程的數據都是明文傳輸的，並且多個隨機數種子來生成秘鑰不容易被破解出來。

⑼ TLS過程（DH 非對稱加密）

TLS 的目的便是解決數據的
一、Record 記錄協議 （對稱加解密）

二、HandShake 握手，揮手
驗證通訊雙方身份
交換加解密的安全套件
協商加密解密參數

當一個TLS會話建立好之後，會使用對稱加密的密鑰去通信，那麼如何實現事先將對稱加密的密鑰傳遞給TLS會話的另一方呢。利用的就是非對稱加密。分對稱加密比對稱加密慢數千倍，所以只是使用對稱加密傳遞之後加密使用的對稱加密的密鑰。之後的加密安全性靠的是對稱加密來解決。

非對稱加密是有一把公鑰和一把私鑰，公鑰可以公開，而私鑰不能。
用公鑰加密成密文，再將密文用私鑰解密就能實現加解密過程。
而用私鑰加密，公鑰解密就是簽名認證過程。
常見的非對稱加密方式分為兩大類

RSA 沒有向前安全性，也就是需要每次的對稱加密密鑰的傳遞都是基於 公鑰加密，服務端私鑰解密。如果服務端的私鑰丟失了，那幾年前的通信數據都有可能被解密。所以這是極度不安全的，私鑰的地位太重了，如果每次的加解密都是臨時生成的密碼來解決安全性，才不會對私鑰的安全性有如此強的依賴。在2013年的棱鏡門事件中，某個CA機構迫於美國政府壓力向其提交了CA的私鑰，這就是十分危險的。如果向前不安全，那麼之前利用該CA私鑰都會全部遭殃。所以這里說的是更安全的 DH類非對稱加密。

下圖就是DH密鑰交換的TLS握手過程

DH 密鑰交換協議，Diffile-Hellman key Exchange，簡稱 DH 或 DHE 。它可以讓雙方在完全沒有對方任何預先信息的條件下通過一個不安全的信道創建一個密鑰。

1、客戶端瀏覽器隨機生成一個值Ra，計算Pa(x,y) = Ra*Q(x,y), Q(x,y)為全世界公認的某個橢圓曲線演算法的基點。將Pa(x,y)發送至伺服器。

2、伺服器隨機生成一個值Rb，計算 Pb(x,y) = Rb * Q(x,y)。將Pb(x,y)發送到客戶端瀏覽器。

3、客戶端計算Sa(x,y) = Ra * Pb(x,y)，伺服器計算Sb(x,y)=Rb*Pa(x,y)

4、演算法保證了Sa=Sb=S, 提取其中的S的x向量作為密鑰。

為了解決上述DH的問題，引入了ECC橢圓曲線，進而進化為 ECDHE 演算法，稱為 Elliptic Curve Diffie-Hellman Key Exchange。ECC和RSA 在288位元組的長度下，破解RSA需要煮沸一勺水的能量，而破解相同位數的ECC 就需要煮沸整個地球水的能量。RSA 為了提高安全性，只能靠增大密鑰位數。尷尬的是現在的超算越來越厲害。量子計算下秀爾演算法可8h內輕松破解2048位的RSA。RSA只能再增大密鑰位數，但是再增大位數，移動端設備就慘了，你增大的密鑰是運營商要收取流量費用的，而且加解密太費電。
ECC 的數學原理是橢圓曲線和離散對數。橢圓曲線很復雜。為了提升性能，還需要選擇一個橢圓曲線，但是它不是真正的橢圓形，下面有圖可以看到，只是運算上用到了橢圓演算法。
但是ECC也有很多問題，1、ECC 可能有後門，如NSA（美國國家安全局發布的一套演算法），這個演算法就是被懷疑被植入後門了。2、而且ECC很多的演算法都被注冊專利了，一不小心就要吃官司，其專利大部分都被黑莓注冊。

ECC 橢圓曲線的定義

ECC 的演算法原理過於復雜，這里表示我也看不懂。點到為止吧。（以後看懂了再來補充）

這里的抓包結果就是用的EC DH E 演算法來進行密鑰交換的。這里選擇的曲線是 secp256r1, 在這個曲線中，基點和參數已經給出了，PubKey 也給出了。
在 TLS1.3 中，一般使用的 X25519 曲線 （蒙哥馬利曲線）

⑽ 用WireShark簡單看看SSL/TLS協議

HTTPS目前是網站標配，否則瀏覽器會提示鏈接不安全，同HTTP相比比，HTTPS提供安全通信，具體原因是多了個「S」層，或者說SSL層[Secure Sockets Layer]，現在一般都是TLS[Transport Layer Security]，它是HTTP 明文 通信變成安全 加密通信 的基礎，SSL/TLS介於應用層和TCP層之間，從應用層數據進行加密再傳輸。安全的核心就在加密上：

如上圖所示，HTTP明文通信經中間路由最終發送給對方，如果中間某個路由節點抓取了數據，就可以直接看到通信內容，甚至可以篡改後，路由給目標對象，如下：

可見HTTP傳輸是不安全的，但，如果傳輸的是只有雙方可校驗的密文，就可以避免被偷竊、篡改，保證傳輸的安全性，這就是SSL/TLS層做的事情。

SSL/TLS協議主要從三方面來保證數據傳輸的安全性：保密、鑒別、完整：

對用戶端而言：怎麼保證訪問的網站就是目標網站？答案就是 證書 。每個HTTPS網站都需要TLS證書，在數據傳輸開始前，服務端先將證書下發到用戶端，由用戶根據證書判斷是否是目標網站。這其中的原理是什麼，證書又是如何標識網站的有效性呢？證書也叫 digital certificate 或者public key certificate，是密碼學中的概念，在TLS中就是指CA證書【 由證書的簽發機構（Certificate Authority，簡稱為 CA）頒布的證書 】，好比是權威部門的公章，WIKI網路解釋如下：

大意就是證書包含了目標站點的身份信息，並可以通過某種方式校驗其合法性，對於任何一個HTTPS網站，你都可以拿到其CA證書公鑰信息，在Chrome瀏覽器中點擊HTTPS網站的鎖標志，就可以查看公鑰信息，並可以導出CA二進制文件：

瀏覽器就是通過這個文件來校驗網站是否安全合法，可以看到，證書其實內置了一個頒發鏈條關系，根證書機構->次級證書機構->次次級->網站自身，只要驗證這個鏈條是安全的，就證明網站合法，背後的技術其實是 信任鏈+RSA的非對稱加密+系統內置根證書 。CA在頒發證書的時候，會用自己的私鑰計算出要頒發證書的簽名，其公鑰是公開的，只要簽名可被公鑰驗證就說明該證書是由該CA頒發的，核心校驗邏輯如下

那麼上級的CA又是如何保證安全呢？重復上述操作即可，最終都是靠根證書來驗證的，根證書的安全性不需要驗證，由系統保證，如此就形成了一個證書的信任鏈，也就能驗證當前網站證書的有效性，證書的信任鏈校驗如下：

TLS協議最大的提升點就是數據的安全，通HTTP通信相比，HTTPS的通信是加密的，在協商階段，通過非對稱加密確定對稱加密使用的秘鑰，之後利用對稱秘鑰進行加密通信，這樣傳輸的數據就是密文，就算中間節點泄漏，也可以保證數據不被竊取，從而保證通信數據的安全性。

第三個問題，雖然中間節點無法竊取數據，但是還是可以隨意更改數據的，那麼怎麼保證數據的完整性呢，這個其實任何數據傳輸中都會有這個問題，通過MAC[Message Authentication Codes]信息摘要演算法就可以解決這個問題，同普通MD5、SHA等對比，MAC消息的散列加入了秘鑰的概念，更加安全，是MD5和SHA演算法的升級版，可以認為TLS完整性是數據保密性延伸，接下來就藉助WireShark看看TLS握手的過程，並看看是如何實現身份鑒別、保密性、完整性的。

HTTPS安全通信簡化來說： 在協商階段用非對稱加密協商好通信的對稱秘鑰 ，然後 用對稱秘鑰加密進行數據通信 ，簡易的WireShark TLS/SSL協商過程示意如下：

細化分離後示意如下：

握手分多個階段，不過一次握手可以完成多個動作，而且也並不是所有類型的握手都是上述模型，因為協商對稱秘鑰的演算法不止一種，所以握手的具體操作也並非一成不變，比如RSA就比ECDHE要簡單的多，目前主流使用的都是ECDHE，具體流程拆分如下：

Client Hello是TLS/SSL握手發起的第一個動作，類似TCP的SYN，Client Hello 階段客戶端會指定版本，隨機數、支持的密碼套件供服務端選擇，具體的包數據如下

啟動TLS握手過程， 提供自己所能支持各種演算法，同時提供一個將來所能用到的隨機數 。

ContentType指示TLS通信處於哪個階段階段，值22代表Handshake，握手階段，Version是TLS的版本1.2，在握手階段，後面鏈接的就是握手協議，這里是Client Hello，值是1，同時還會創建一個隨機數random給Server，它會在生成session key【對稱密鑰】時使用。之後就是支持的供服務端選擇的密碼套件，接下來等服務端返回。

Handshake Type: Server Hello (2)，作為對Client Hello的響應 ， 確定使用的加密套件 : TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)，密鑰協商使用 ECDHE，簽名使用 RSA，
數據通信通信使用 AES 對稱加密，並且密鑰長度是128位，GCM分組，同時生成一個服務端的random及會話ID回傳。

這一步伺服器將配置的證書【鏈】發送給客戶端，客戶端基於上文所述的證書鏈校驗證書的有效性，這里發送的證書是二進制格，可以利用wireshark右鍵「Export Packet Bytes」功能，導出.CER格式的證書。如下可以看到傳輸的證書鏈。

導出的CER格式的證書如下，最關鍵的就其公鑰跟數字簽名。

Server Key Exchange是針對選定的ECDHE協商所必須的步驟，Diffie-Hellman模型解釋如下：

大意就是ephemeral Diffie-Hellman不會使用證書中的靜態公鑰參與對稱秘鑰的生成，而是需要服務端與客戶端通過彼此協商確定對稱秘鑰，而D-H演算法模型需要兩對非對稱秘鑰對，各端保留自己的私鑰，同時握有雙方的公鑰，然後基於D-H演算法雙端可以算出一樣的對稱加密秘鑰，而這就需要C/S互傳自己的公鑰

服務端做完這一步，其實ECDHE演算法中服務端需要提供的信息已經結束，發送 Server Hello Done告訴客戶端，然後等待客戶端回傳它的D-H公鑰。

演算法：

其中p和g是公開的DH參數，只要P是一個足夠大的數，在不知道私鑰的情況下，即使截獲了雙方的公鑰，也是很難破解的。

客戶端收到服務端的證書後，利用信任鏈檢測證書有效性，同時也會同Server Key Exchange 類似，將自己的Diffie-Hellman公鑰發送給Server端，

至此，ECDHE協商所需要的信息都傳輸完畢， 雙方都可以基於ECDHE演算法算出的共享密鑰，同時結合之前的隨機數生成最終的對稱加密秘鑰：

之後客戶端發送Change Cipher Spec與 Encrypted Handshake Message標識握手完成，同時傳輸一個加密的數據給Server，驗證雙方確立的秘鑰是否正確，這就需要服務端也要重復這個操作給客戶端，這樣才能驗證彼此的加解密一致，即服務端也要來一次Encrypted Handshake Message回傳給客戶端校驗，

走完如上流程，雙方就確認了正確的對稱加密通道，後面就是TLS的數據通信，其Record Layer的ContentType 也會變成 Content Type: Application Data (23)：

最終對稱會話密鑰包含三部分因子：

Client Hello與Server Hello階段交換的隨機數，是為了提高秘鑰的「隨機」程度而進行的，這樣有助於提高會話密鑰破解難度。

HTTPS通過加密與完整性校驗可以防止數據包破解與篡改，但對於主動授信的抓包操作是沒法防護，比如Charles抓包，在這個場景用戶已經風險，並且將Charles提供的證書信任為根證書，這從源頭上構建了一條虛擬的信任鏈：在握手階段，Charles利用自己的公鑰，生成客戶端可以信任的篡改證書，從而可以充作中間人進而抓包，所謂中間人攻擊，感覺跟Https抓包原理一樣，都是要強制添加一個自己的信任根證書。