參考：https://juejin.cn/post/6844903667577929742
參考：https://zhuanlan.zhihu.com/p/594278172

基礎(chǔ)理論入門

參考：https://www.bilibili.com/video/BV1KY411x7Jp/?spm_id_from=333.788&vd_source=cc0e43b449de7e8663ca1f89dd5fea7d

HTTPS

如上圖所示，http請求和響應(yīng)的報文都是明文的，只要有點http基礎(chǔ)的人都能看得懂報文里面的內(nèi)容，所以需要給http增加安全性，也就是https。https并不是一個單獨的協(xié)議，只不過在http的基礎(chǔ)上用TLS/SSL進(jìn)行加密。

SSL是TLS的前身，他們都是加密安全協(xié)議。現(xiàn)在絕大部分瀏覽器都不支持SSL，而是支持TLS，不過SSL的名聲很大(openSSL庫都是以SSL命名的)，所以很多人會把這連個名字混用TLS/SSL，兩者關(guān)系就像是王老吉和加多寶。

對稱加密

加密和解密使用同樣的規(guī)則算法(鑰匙)，這就是對稱加密，如果第三方知道加密的規(guī)則后，就很同意破解了。

非對稱加密

如上圖所示，最終混出來的“便便色”只有小青和小紅知道，他們就可以用這個“便便色”秘鑰給數(shù)據(jù)進(jìn)行加密了，這就是非對稱加密的核心所在。用兩個秘鑰來進(jìn)行加密和解密，公開秘鑰是所有人都知道的秘鑰，私有秘鑰僅僅是持有方才有的秘鑰。

一般來說，私鑰就放在服務(wù)器里，數(shù)據(jù)經(jīng)過公鑰加密就只能被私鑰解密，數(shù)據(jù)經(jīng)過私鑰加密就只能被公鑰解密。

如果用到客戶端和服務(wù)端的話，就是服務(wù)端擁有自己成對的私鑰和公鑰，然后公布自己的公鑰讓客戶端知道，客戶端用公鑰把自己的數(shù)據(jù)進(jìn)行加密，加密后用公鑰反而無法解密這段數(shù)據(jù)，一定要用服務(wù)端的私鑰才能解密，這樣的非對稱加密其實也叫公鑰加密，因為不同于對稱加密中只使用一把私鑰性加密。對稱加密和非對稱加密TLS都有用上，后面介紹。

證書

雖然我們現(xiàn)在可以對數(shù)據(jù)進(jìn)行加密，但是我們還是不知道和我溝通的是否是自己想要溝通的對象，比如B站的域名www.bilibili.com很多人容易輸入錯誤，比如www.bi1ibili.com，這樣就可能會有不法分子偽裝B站域名讓你來訪問。還好HTTPS解決了這個問題，因為服務(wù)端需要申請SSL證書，來證明這個域名就是大家所熟知的B站。

SSL證書其實就是保存在源服務(wù)器的數(shù)據(jù)文件，要讓SSL證書生效就需要向CA申請，也就是Certificate Authority證書授權(quán)中心，這是第三方的機(jī)構(gòu)，這樣大家都來信任這個機(jī)構(gòu)頒發(fā)的證書，這個證書表明域名是屬于誰的，日期等信息以外，重要的是這個證書里還包括了特定的公鑰和私鑰。簡單來說服務(wù)器安裝了SSL證書以后，用戶就可以通過HTTPS來訪問服務(wù)器了，瀏覽器也會把HTTP默認(rèn)的端口80改成HTTPS默認(rèn)的443。

那現(xiàn)在瀏覽器通過HTTPS訪問服務(wù)器具體會有哪些變化呢？根據(jù)不同的TLS版本會有不同的變化，這里就以TLS1.2為例子進(jìn)行講解。

TLS握手過程

首先正常的TCP三次握手是不變的。三次握手后，客戶端發(fā)送了一個Client Hello給服務(wù)端，客戶端就會告訴服務(wù)端支持的TLS 1.2版本和支持的加密套件，這里16個加密套件可以理解為不同的加密算法組合，然后生成一個隨機(jī)數(shù)發(fā)給服務(wù)端，隨機(jī)數(shù)的作用等會告訴大家。

服務(wù)端收到客戶端打招呼，當(dāng)然也要和客戶端打招呼，所以接下來就是Server Hello發(fā)給客戶端，在響應(yīng)報文里面會告訴客戶端，服務(wù)端確認(rèn)支持的TLS版本以及選擇的加密套件，并且服務(wù)器也生成一個隨機(jī)數(shù)發(fā)給客戶端，隨機(jī)數(shù)的作用等會介紹。

接下來服務(wù)器會再發(fā)送一個響應(yīng)，來出示服務(wù)器自己的證書，這樣瀏覽器就可以根據(jù)對照自己的證書信任列表來確認(rèn)這個服務(wù)器是否可信。

發(fā)了證書，當(dāng)然少不了公鑰了，于是下一步Server Key Exchange這里，服務(wù)器就把公鑰發(fā)送給了客戶端，注意不會傻傻的把私鑰發(fā)出去。如果服務(wù)器也想要客戶端的證書也會在這里發(fā)出請求，比如登錄網(wǎng)銀就可能需要這個步驟了。

服務(wù)器一下發(fā)了這么多響應(yīng)，最后還要告訴客戶端發(fā)送完了，于是就是Server Hello Done。

打個招呼花了這么久，而且截止到目前這些請求和響應(yīng)依舊還未進(jìn)行加密?，F(xiàn)在就輪到客戶端來處理這些響應(yīng)了。Client Key Exchange這一步是個重點也是難點，客戶端會生成第三個隨機(jī)數(shù)，也叫預(yù)主秘鑰。這第三個隨機(jī)數(shù)會用剛剛收到的公鑰進(jìn)行加密，并且把這個加密后的隨機(jī)數(shù)發(fā)送給服務(wù)器，正是這里的Pubkey顯示的隨機(jī)數(shù)。

接下來就是Change Cipher Spec，這一步就是告訴服務(wù)器往后的數(shù)據(jù)就用商議好的算法和秘鑰來加密了。最后Encrypted Handshake Message表示客戶端這邊的TLS協(xié)商已經(jīng)沒有問題了，加密開始。

同樣的后面服務(wù)器也發(fā)來了Encrypted Handshake Message，表示服務(wù)器這邊準(zhǔn)備好了，這里也表示著TLS的握手已經(jīng)成功了，可以給數(shù)據(jù)加密進(jìn)行交換了。

握手總結(jié)

1、客戶端向服務(wù)端打招呼，并且把自己支持的TLS版本，加密套件發(fā)給服務(wù)端，同時還生成了一個隨機(jī)數(shù)給服務(wù)端，這里就稱為第一個隨機(jī)數(shù)(隨機(jī)數(shù)用來生成對稱密鑰)。
2、服務(wù)端打招呼，服務(wù)端確認(rèn)支持的TLS版本以及選擇的加密套件，并且服務(wù)器也生成一個隨機(jī)數(shù)發(fā)給客戶端，這里就稱為第二個隨機(jī)數(shù)。
3、4、5、接著服務(wù)端把證書和公鑰發(fā)送給客戶端，都發(fā)送完畢就告知客戶端。
6、現(xiàn)在客戶端這邊生成隨機(jī)數(shù)，我們稱為第三個隨機(jī)數(shù)——預(yù)主秘鑰，這個預(yù)主秘鑰不會直接發(fā)送出去，而是用剛剛收到的公鑰進(jìn)行加密后再發(fā)送出去，然后客戶端這邊的TLS協(xié)商已經(jīng)沒問題了，加密開始。
服務(wù)端收到加密后的預(yù)主秘鑰以后，會用自己的私鑰進(jìn)行解密，這樣服務(wù)器就知道預(yù)主秘鑰了，而且只有客戶端和服務(wù)端知道預(yù)主秘鑰，因為沒有直接傳輸，沒有其他人知道這預(yù)主秘鑰是什么，除非私鑰被泄露了。

7、最后客戶度用預(yù)主秘鑰，第一隨機(jī)數(shù)和第二隨機(jī)數(shù)計算出會話秘鑰，服務(wù)端也用預(yù)主秘鑰，第一隨機(jī)數(shù)和第二隨機(jī)數(shù)計算出會話秘鑰，各自得到的會話秘鑰是相同的(后續(xù)對稱加密)，這里的道理和前面說的“便便色”是同樣的道理。

也就是說前面的步驟都是非對稱加密，為了得到這個會話秘鑰，會面的會話大家都只使用這個會話秘鑰對數(shù)據(jù)進(jìn)行加密，也就是后面使用的對稱加密，大家都使用同一個私鑰。后面不使用非對稱加密是因為大家都能看到消耗資源非常大。而且得到會話秘鑰以后就沒人知道秘鑰是什么了，因此后面對稱加密。如果與其他服務(wù)器溝通就是建立新的會話，會話秘鑰也不相同，會話秘鑰只應(yīng)用在當(dāng)前會話，更加提高了安全性。

TLS 定義(記錄層/握手層)

SSL(Secure Sockets Layer) 安全套接層，是一種安全協(xié)議，經(jīng)歷了 SSL 1.0、2.0、3.0 版本后發(fā)展成了標(biāo)準(zhǔn)安全協(xié)議 - TLS(Transport Layer Security) 傳輸層安全性協(xié)議。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。

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

HTTPS = HTTP over TLS

只需配置瀏覽器和服務(wù)器相關(guān)設(shè)置開啟 TLS，即可實現(xiàn) HTTPS。TLS 高度解耦，可裝可卸，與上層高級應(yīng)用層協(xié)議相互協(xié)作又相互獨立。

加密

TLS/SSL 的功能實現(xiàn)主要依賴于三類基本算法：散列函數(shù) Hash、對稱加密、非對稱加密。利用非對稱加密實現(xiàn)身份認(rèn)證和密鑰協(xié)商，對稱加密算法采用協(xié)商的密鑰對數(shù)據(jù)加密，基于散列函數(shù)驗證信息的完整性。

TLS 的基本工作方式是，客戶端使用非對稱加密與服務(wù)器進(jìn)行通信，實現(xiàn)身份驗證并協(xié)商對稱加密使用的密鑰，然后對稱加密算法采用協(xié)商密鑰對信息以及信息摘要進(jìn)行加密通信，不同的節(jié)點之間采用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。

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

記錄層

記錄協(xié)議負(fù)責(zé)在傳輸連接上交換的所有底層消息，并且可以配置加密。每一條 TLS 記錄以一個短標(biāo)頭開始。標(biāo)頭包含記錄內(nèi)容的類型 (或子協(xié)議)、協(xié)議版本和長度。原始消息經(jīng)過分段 (或者合并)、壓縮、添加認(rèn)證碼、加密轉(zhuǎn)為 TLS 記錄的數(shù)據(jù)部分。

分片 (Fragmentation)

記錄層將信息塊分割成攜帶 2^14 字節(jié) (16KB) 或更小塊的數(shù)據(jù)的 TLSPlaintext 記錄。
記錄協(xié)議傳輸由其他協(xié)議層提交給它的不透明數(shù)據(jù)緩沖區(qū)。如果緩沖區(qū)超過記錄的長度限制（2^14），記錄協(xié)議會將其切分成更小的片段。反過來也是可能的，屬于同一個子協(xié)議的小緩沖區(qū)也可以組合成一個單獨的記錄。

struct {
  uint8 major, minor;
} ProtocolVersion;

enum {
  change_cipher_spec(20),
  alert(21),
  handshake(22),
  application_data(23), (255)
} ContentType;

struct {
  ContentType type; // 用于處理封閉片段的較高級協(xié)議
  ProtocolVersion version; // 使用的安全協(xié)議版本
  uint16 length; // TLSPlaintext.fragment 的長度（以字節(jié)為單位），不超過 2^14
  opaque fragment[TLSPlaintext.length]; // 透明的應(yīng)用數(shù)據(jù)，被視為獨立的塊，由類型字段指定的較高級協(xié)議處理
} TLSPlaintext;

記錄壓縮和解壓縮 (Record compression and decompression)

壓縮算法將 TLSPlaintext 結(jié)構(gòu)轉(zhuǎn)換為 TLSCompressed 結(jié)構(gòu)。如果定義 CompressionMethod 為 null 表示不壓縮。

struct {
  ContentType type; // same as TLSPlaintext.type
  ProtocolVersion version; // same as TLSPlaintext.version
  uint16 length; // TLSCompressed.fragment 的長度，不超過 2^14 + 1024
  opaque fragment[TLSCompressed.length];
} TLSCompressed;

空或標(biāo)準(zhǔn)流加密 (Null or standard stream cipher)

流加密（BulkCipherAlgorithm）將 TLSCompressed.fragment 結(jié)構(gòu)轉(zhuǎn)換為流 TLSCiphertext.fragment 結(jié)構(gòu)。

stream-ciphered struct {
    opaque content[TLSCompressed.length];
    opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;

MAC 產(chǎn)生方法如下：

HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment));

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

MAC(Message authentication code) - 消息認(rèn)證碼

注意，MAC 是在加密之前計算的。流加密加密整個塊，包括 MAC。對于不使用同步向量 (例如 RC4)
的流加密，從一個記錄結(jié)尾處的流加密狀態(tài)僅用于后續(xù)數(shù)據(jù)包。如果 CipherSuite 是TLS_NULL_WITH_NULL_NULL，則加密由身份操作 (數(shù)據(jù)未加密，MAC 大小為零，暗示不使用 MAC)組成。TLSCiphertext.length 是 TLSCompressed.length 加上CipherSpec.hash_size。

CBC 塊加密 (分組加密)

塊加密（如 RC2 或 DES），將 TLSCompressed.fragment 結(jié)構(gòu)轉(zhuǎn)換為塊 TLSCiphertext.fragment 結(jié)構(gòu)。

block-ciphered struct {
  opaque content[TLSCompressed.length];
  opaque MAC[CipherSpec.hash_size];
  uint8 padding[GenericBlockCipher.padding_length];
  uint8 padding_length;
} GenericBlockCipher;

padding: 添加的填充將明文長度強(qiáng)制為塊密碼塊長度的整數(shù)倍。填充可以是長達(dá) 255 字節(jié)的任何長度，只要滿足 TLSCiphertext.length 是塊長度的整數(shù)倍。長度大于需要的值可以阻止基于分析交換信息長度的協(xié)議攻擊。填充數(shù)據(jù)向量中的每個 uint8 必須填入填充長度值 (即 padding_length)。

padding_length: 填充長度應(yīng)該使得 GenericBlockCipher 結(jié)構(gòu)的總大小是加密塊長度的倍數(shù)。合法值范圍從零到 255（含）。該長度指定 padding_length 字段本身除外的填充字段的長度加密塊的數(shù)據(jù)長度（TLSCiphertext.length）是 TLSCompressed.length，CipherSpec.hash_size 和 padding_length 的總和加一

示例: 如果塊長度為 8 字節(jié)，壓縮內(nèi)容長度（TLSCompressed.length）為 61 字節(jié)，MAC 長度為 20 字節(jié)，則填充前的長度為 82 字節(jié)（padding_length 占 1 字節(jié)）。

因此，為了使總長度為塊長度 (8 字節(jié)) 的偶數(shù)倍，模 8 的填充長度必須等于 6，所以填充長度可以為 6，14，22 等。如果填充長度是需要的最小值，比如 6，填充將為 6 字節(jié)，每個塊都包含值 6。因此，塊加密之前的 GenericBlockCipher 的最后 8 個八位字節(jié)將為 xx 06 06 06 06 06 06 06，其中 xx 是 MAC 的最后一個八位字節(jié)。

XX  - 06 06 06 06 06 06 - 06
MAC -     padding[6]    - padding_length

記錄有效載荷保護(hù) (Record payload protection)

加密和 MAC 功能將 TLSCompressed 結(jié)構(gòu)轉(zhuǎn)換為 TLSCiphertext。記錄的 MAC 還包括序列號，以便可以檢測到丟失，額外或重復(fù)的消息。

struct {
  ContentType type; // same
  ProtocolVersion version; // same
  uint16 length; // TLSCiphertext.fragment 的長度，不超過 2^14 + 2048
  select (CipherSpec.cipher_type) {
    case stream: GenericStreamCipher;
    case block: GenericBlockCipher;
  } fragment; // TLSCompressed.fragment 的加密形式，帶有 MAC
} TLSCiphertext;

注意 這里提到的都是先 MAC 再加密，是基于 RFC 2246 的方案 (TLS 1.0) 寫的。但新的方案選擇先加密再 MAC，這種替代方案中，首先對明文和填充進(jìn)行加密，再將結(jié)果交給 MAC 算法。這可以保證主動網(wǎng)絡(luò)攻擊者不能操縱任何加密數(shù)據(jù)。

密鑰計算 (Key calculation)

記錄協(xié)議需要一種算法，從握手協(xié)議提供的安全性參數(shù)生成密鑰、IV 和 MAC secret。
主密鑰 (Master secret): 在連接中雙方共享的一個 48 字節(jié)的密鑰
客戶隨機(jī)數(shù) (client random): 由客戶端提供的 32 字節(jié)值
服務(wù)器隨機(jī)數(shù) (server random): 由服務(wù)器提供的 32 字節(jié)值

握手層

• 握手協(xié)議的職責(zé)是生成通信過程所需的共享密鑰和進(jìn)行身份認(rèn)證。這部分使用無密碼套件，為防止數(shù)據(jù)被竊聽，通過公鑰密碼或 Diffie-Hellman 密鑰交換技術(shù)通信。
• 密碼規(guī)格變更協(xié)議，用于密碼切換的同步，是在握手協(xié)議之后的協(xié)議。握手協(xié)議過程中使用的協(xié)議是“不加密”這一密碼套件，握手協(xié)議完成后則使用協(xié)商好的密碼套件。
• 警告協(xié)議，當(dāng)發(fā)生錯誤時使用該協(xié)議通知通信對方，如握手過程中發(fā)生異常、消息認(rèn)證碼錯誤、數(shù)據(jù)無法解壓縮等。
• 應(yīng)用數(shù)據(jù)協(xié)議，通信雙方真正進(jìn)行應(yīng)用數(shù)據(jù)傳輸?shù)膮f(xié)議，傳送過程通過 TLS 應(yīng)用數(shù)據(jù)協(xié)議和 TLS 記錄協(xié)議來進(jìn)行傳輸。

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

握手協(xié)議消息的標(biāo)頭信息包含消息類型（1 字節(jié)）和長度（3 字節(jié)），余下的信息則取決于消息類型：

struct {
  HandshakeType msg_type;
  uint24 length;
  HandshakeMessage message;
} Handshake;

完整握手

每一個 TLS 連接都會以握手開始。如果客戶端此前并未與服務(wù)器建立會話，那么雙方會執(zhí)行一次完整的握手流程來協(xié)商 TLS 會話。握手過程中，客戶端和服務(wù)器將進(jìn)行以下四個主要步驟:

• 交換各自支持的功能，對需要的連接參數(shù)達(dá)成一致
• 驗證出示的證書，或使用其他方式進(jìn)行身份驗證
• 對將用于保護(hù)會話的共享主密鑰達(dá)成一致
• 驗證握手消息并未被第三方團(tuán)體修改

下面介紹最常見的握手規(guī)則，一種不需要驗證客戶端身份但需要驗證服務(wù)器身份的握手:

ClientHello

這條消息將客戶端的功能和首選項傳送給服務(wù)器。

• Version: 協(xié)議版本（protocol version）指示客戶端支持的最佳協(xié)議版本。
• Random: 一個 32 字節(jié)數(shù)據(jù)，28 字節(jié)是隨機(jī)生成的 (圖中的 Random Bytes)；剩余的 4 字節(jié)包含額外的信息，與客戶端時鐘有關(guān) (圖中使用的是 GMT Unix Time)。在握手時，客戶端和服務(wù)器都會提供隨機(jī)數(shù)，客戶端的暫記作 random_C (用于后續(xù)的密鑰的生成)。這種隨機(jī)性對每次握手都是獨一無二的，在身份驗證中起著舉足輕重的作用。它可以防止重放攻擊，并確認(rèn)初始數(shù)據(jù)交換的完整性。
• Session ID: 在第一次連接時，會話 ID（session ID）字段是空的，這表示客戶端并不希望恢復(fù)某個已存在的會話。典型的會話 ID 包含 32 字節(jié)隨機(jī)生成的數(shù)據(jù)，一般由服務(wù)端生成通過 ServerHello 返回給客戶端。
• Cipher Suites: 密碼套件（cipher suite）塊是由客戶端支持的所有密碼套件組成的列表，該列表是按優(yōu)先級順序排列的。
• Compression: 客戶端可以提交一個或多個支持壓縮的方法。默認(rèn)的壓縮方法是 null，代表沒有壓縮
• Extensions: 擴(kuò)展（extension）塊由任意數(shù)量的擴(kuò)展組成。這些擴(kuò)展會攜帶額外數(shù)據(jù)

ServerHello

是將服務(wù)器選擇的連接參數(shù)傳回客戶端。

這個消息的結(jié)構(gòu)與 ClientHello 類似，只是每個字段只包含一個選項，其中包含服務(wù)端的 random_S 參數(shù) (用于后續(xù)的密鑰協(xié)商)。服務(wù)器無需支持客戶端支持的最佳版本。如果服務(wù)器不支持與客戶端相同的版本，可以提供某個其他版本以期待客戶端能夠接受圖中的 Cipher Suite 是后續(xù)密鑰協(xié)商和身份驗證要用的加密套件，此處選擇的密鑰交換與簽名算法是 ECDHE_RSA，對稱加密算法是 AES-GCM，后面會講到這個。還有一點默認(rèn)情況下 TLS 壓縮都是關(guān)閉的，因為 CRIME 攻擊會利用 TLS 壓縮恢復(fù)加密認(rèn)證 cookie，實現(xiàn)會話劫持，而且一般配置 gzip 等內(nèi)容壓縮后再壓縮 TLS 分片效益不大又額外占用資源，所以一般都關(guān)閉 TLS 壓縮。

Certificate

典型的 Certificate 消息用于攜帶服務(wù)器 X.509 證書鏈。

服務(wù)器必須保證它發(fā)送的證書與選擇的算法套件一致。比方說，公鑰算法與套件中使用的必須匹配。除此以外，一些密鑰交換算法依賴嵌入證書的特定數(shù)據(jù)，而且要求證書必須以客戶端支持的算法簽名。所有這些都表明服務(wù)器需要配置多個證書（每個證書可能會配備不同的證書鏈）。

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

ServerKeyExchange

攜帶密鑰交換需要的額外數(shù)據(jù)。ServerKeyExchange 是可選的，消息內(nèi)容對于不同的協(xié)商算法套件會存在差異。部分場景下，比如使用 RSA 算法時，服務(wù)器不需要發(fā)送此消息(下面秘鑰交換算法里有講)。

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

比如基于 DH 算法的握手過程中，需要單獨發(fā)送一條 ServerKeyExchange 消息帶上 DH 參數(shù)。

ServerHelloDone

表明服務(wù)器已經(jīng)將所有預(yù)計的握手消息發(fā)送完畢。在此之后，服務(wù)器會等待客戶端發(fā)送消息。

verify certificate

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

• 證書鏈的可信性 trusted certificate path;
• 證書是否吊銷 revocation，有兩類方式 - 離線 CRL 與在線 OCSP，不同的客戶端行為會不同;
• 有效期 expiry date，證書是否在有效時間范圍;
• 域名 domain，核查證書域名是否與當(dāng)前的訪問域名匹配;

由 PKI 體系 的內(nèi)容可知，對端發(fā)來的證書簽名是 CA 私鑰加密的，接收到證書后，先讀取證書中的相關(guān)的明文信息，采用相同的散列函數(shù)計算得到信息摘要，然后利用對應(yīng) CA 的公鑰解密簽名數(shù)據(jù)，對比證書的信息摘要，如果一致，則可以確認(rèn)證書的合法性；然后去查詢證書的吊銷情況等。

ClientKeyExchange

合法性驗證通過之后，客戶端計算產(chǎn)生隨機(jī)數(shù)字的預(yù)主密鑰（Pre-master），并用證書公鑰加密，發(fā)送給服務(wù)器并攜帶客戶端為密鑰交換提供的所有信息。這個消息受協(xié)商的密碼套件的影響，內(nèi)容隨著不同的協(xié)商密碼套件而不同。

此時客戶端已經(jīng)獲取全部的計算協(xié)商密鑰需要的信息: 兩個明文隨機(jī)數(shù) random_C 和 random_S 與自己計算產(chǎn)生的 Pre-master，然后得到協(xié)商密鑰(用于之后的消息加密)。

enc_key = PRF(Pre_master, "master secret", random_C + random_S)

圖中使用的是 ECDHE 算法，ClientKeyExchange 傳遞的是 DH 算法的客戶端參數(shù)，如果使用的是 RSA 算法則此處應(yīng)該傳遞加密的預(yù)主密鑰。

ChangeCipherSpec

通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信。

注意 ChangeCipherSpec 不屬于握手消息，它是另一種協(xié)議，只有一條消息，作為它的子協(xié)議進(jìn)行實現(xiàn)。

Finished (Encrypted Handshake Message)

Finished 消息意味著握手已經(jīng)完成。消息內(nèi)容將加密，以便雙方可以安全地交換驗證整個握手完整性所需的數(shù)據(jù)。

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

verify_data = PRF(master_secret, finished_label, Hash(handshake_messages))

因為 Finished 消息是加密的，并且它們的完整性由協(xié)商 MAC 算法保證，所以主動網(wǎng)絡(luò)攻擊者不能改變握手消息并對 vertify_data 的值造假。在 TLS 1.2 版本中，F(xiàn)inished 消息的長度默認(rèn)是 12 字節(jié)（96 位），并且允許密碼套件使用更長的長度。在此之前的版本，除了 SSL 3 使用 36 字節(jié)的定長消息，其他版本都使用 12 字節(jié)的定長消息。

Server

服務(wù)器用私鑰解密加密的 Pre-master 數(shù)據(jù)，基于之前交換的兩個明文隨機(jī)數(shù) random_C 和 random_S，同樣計算得到協(xié)商密鑰: enc_key = PRF(Pre_master, “master secret”, random_C + random_S);
同樣計算之前所有收發(fā)信息的 hash 值，然后用協(xié)商密鑰解密客戶端發(fā)送的 verify_data_C，驗證消息正確性;

change_cipher_spec

服務(wù)端驗證通過之后，服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信（圖中多了一步 New Session Ticket，此為會話票證，會在會話恢復(fù)中解釋）;

Finished (Encrypted Handshake Message)

服務(wù)器也結(jié)合所有當(dāng)前的通信參數(shù)信息生成一段數(shù)據(jù) (verify_data_S) 并采用協(xié)商密鑰 session secret (enc_key) 與算法加密并發(fā)送到客戶端;

握手結(jié)束

客戶端計算所有接收信息的 hash 值，并采用協(xié)商密鑰解密 verify_data_S，驗證服務(wù)器發(fā)送的數(shù)據(jù)和密鑰，驗證通過則握手完成;

加密通信

開始使用協(xié)商密鑰與算法進(jìn)行加密通信。

密鑰交換和簽名算法

常用的密鑰交換和簽名算法

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

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

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

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

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

• 在 RSA 密鑰交換中，瀏覽器使用證書提供的 RSA 公鑰加密相關(guān)信息，如果服務(wù)端能解密，意味著服務(wù)端擁有與公鑰對應(yīng)的私鑰，同時也能算出對稱加密所需密鑰。密鑰交換和服務(wù)端認(rèn)證合并在一起。

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

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

• RSA ：RSA 密鑰交換 + 無需簽名
• ECDHE_RSA：ECDHE 密鑰交換 + RSA 簽名
• ECDHE_ECDSA ： ECDHE 密鑰交換 + ECDSA 簽名

比如我的網(wǎng)站使用的加密套件是 ECDHE + RSA，可以看到數(shù)字簽名算法是 sha256 哈希加 RSA 加密，在 PKI 體系一節(jié)中講了簽名是服務(wù)器信息摘要的哈希值加密生成的。

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

以上內(nèi)容來自本文: 開始使用 ECC 證書
關(guān)于 ECC 證書的更多細(xì)節(jié)可見文檔: ECC Cipher Suites for TLS - RFC4492

RSA 密鑰交換和 DH 密鑰交換的區(qū)別

使用 RSA 進(jìn)行密鑰交換的握手過程與前面說明的基本一致，只是沒有 ServerKeyExchange 消息，其中協(xié)商密鑰涉及到三個參數(shù) (客戶端隨機(jī)數(shù) random_C、服務(wù)端隨機(jī)數(shù) random_S、預(yù)主密鑰Premaster secret)。

其中前兩個隨機(jī)數(shù)和協(xié)商使用的算法是明文的很容易獲取，最后一個預(yù)主秘鑰 Premaster secret 客戶端會用服務(wù)器提供的公鑰加密后傳輸給服務(wù)器 (密鑰交換)，如果這個預(yù)主密鑰被截取并破解，則協(xié)商密鑰也可以被破解。

RSA 算法的細(xì)節(jié)見: wiki 和 RSA算法原理（二）- 阮一峰
RSA 的算法核心思想是利用了極大整數(shù) 因數(shù)分解 的計算復(fù)雜性

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

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

服務(wù)器通過私鑰將客戶端隨機(jī)數(shù) random_C，服務(wù)端隨機(jī)數(shù) random_S，服務(wù)端 DH 參數(shù) Server params 簽名生成 signature，然后在 ServerKeyExchange 消息中發(fā)送服務(wù)端 DH 參數(shù)和該簽名；

客戶端收到后用服務(wù)器給的公鑰解密驗證簽名，并在 ClientKeyExchange 消息中發(fā)送客戶端 DH 參數(shù) Client params；

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

基于 RSA 算法與 DH 算法的握手最大的區(qū)別就在于密鑰交換與身份認(rèn)證。

• 前者客戶端使用公鑰加密預(yù)主密鑰并發(fā)送給服務(wù)端完成密鑰交換，服務(wù)端利用私鑰解密完成身份認(rèn)證。
• 后者利用各自發(fā)送的 DH 參數(shù)完成密鑰交換，服務(wù)器私鑰簽名數(shù)據(jù)，客戶端公鑰驗簽完成身份認(rèn)證。

關(guān)于 DH 算法如何生成預(yù)主密鑰，推薦看下 Wiki 和 Ephemeral Diffie-Hellman handshake
其核心思想是利用了 離散對數(shù)問題 的計算復(fù)雜性

原根：假設(shè)一個整數(shù) g 對于質(zhì)數(shù) P 來說是原根，那么 g^i mod P (1 ≦ i < P) 的結(jié)果各不相同，且其結(jié)果按一定順序排列后是 1 到 P-1 的所有整數(shù)，例子。

離散對數(shù)：如果對于一個整數(shù) n 和質(zhì)數(shù) P 的一個原根 g，可以找到一個唯一的指數(shù) i，使得 n = g^i mod P (0 ≦ i < P)，那么指數(shù) i 稱為 n 的以 g 為基數(shù)的模 P 的離散對數(shù)

Diffie-Hellman 算法的有效性依賴于計算離散對數(shù)的難度，其含義是：當(dāng)已知大素數(shù) P 和它的一個原根 g 后，對給定的 n，要計算 i，被認(rèn)為是很困難的，而給定 i 計算 n 卻相對容易

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

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

• Alice 計算 A = g^a mod P，并把 A(公開，對應(yīng)一個公鑰) 發(fā)給 Bob

• Bob 計算 B = g^b mod P，并把 B(公開，對應(yīng)一個公鑰) 發(fā)給 Alice

• 雙方計算出共享密鑰，K = B^a mod P = A^b mod P (= g^ab mod P)

對于 Alice 和 Bob 來說通過對方發(fā)過來的公鑰參數(shù)和自己手中的私鑰可以得到最終相同的密鑰
而第三方最多知道 P g A B，想得到私鑰和最后的密鑰很困難，當(dāng)然前提是 a b P 足夠大 (RFC3526 文檔中有幾個常用的大素數(shù)可供使用)，否則暴力破解也有可能試出答案，至于 g 一般取個較小值就可以
如下幾張圖是實際 DH 握手發(fā)送的內(nèi)容:

可以看到雙方發(fā)給對方的參數(shù)中攜帶了一個公鑰值，對應(yīng)上述的 A 和 B。

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

關(guān)于 橢圓曲線密碼學(xué) - ECC，推薦看下 A Primer on Elliptic Curve Cryptography - 原文 - 譯文

客戶端身份驗證

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

相比之下，服務(wù)器通過發(fā)送 CertificateRequest 消息請求對客戶端進(jìn)行身份驗證。消息中列出所有可接受的客戶端證書。作為響應(yīng)，客戶端發(fā)送自己的 Certificate 消息（使用與服務(wù)器發(fā)送證書相同的格式），并附上證書。此后，客戶端發(fā)送 CertificateVerify 消息，證明自己擁有對應(yīng)的私鑰。

只有已經(jīng)過身份驗證的服務(wù)器才被允許請求客戶端身份驗證?；谶@個原因，這個選項也被稱為相互身份驗證（mutual authentication）。

CertificateRequest

在 ServerHello 的過程中發(fā)出，請求對客戶端進(jìn)行身份驗證，并將其接受的證書的公鑰和簽名算法傳送給客戶端。

它也可以選擇發(fā)送一份自己接受的證書頒發(fā)機(jī)構(gòu)列表，這些機(jī)構(gòu)都用其可分辨名稱來表示:

struct {
  ClientCertificateType certificate_types;
  SignatureAndHashAlgorithm supported_signature_algorithms;
  DistinguishedName certificate_authorities;
} CertificateRequest;

CertificateVerify

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

struct {
  Signature handshake_messages_signature;
} CertificateVerify;

會話恢復(fù)

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

希望恢復(fù)早先會話的客戶端將適當(dāng)?shù)?Session ID 放入 ClientHello 消息，然后提交。服務(wù)器如果同意恢復(fù)會話，就將相同的 Session ID 放入 ServerHello 消息返回，接著使用之前協(xié)商的主密鑰生成一套新的密鑰，再切換到加密模式，發(fā)送 Finished 消息。

客戶端收到會話已恢復(fù)的消息以后，也進(jìn)行相同的操作。這樣的結(jié)果是握手只需要一次網(wǎng)絡(luò)往返。
Session ID 由服務(wù)器端支持，協(xié)議中的標(biāo)準(zhǔn)字段，因此基本所有服務(wù)器都支持，服務(wù)器端保存會話 ID 以及協(xié)商的通信信息，占用服務(wù)器資源較多。

用來替代服務(wù)器會話緩存和恢復(fù)的方案是使用會話票證（Session ticket）。使用這種方式，除了所有的狀態(tài)都保存在客戶端（與 HTTP Cookie 的原理類似）之外，其消息流與服務(wù)器會話緩存是一樣的。
其思想是服務(wù)器取出它的所有會話數(shù)據(jù)（狀態(tài)）并進(jìn)行加密 (密鑰只有服務(wù)器知道)，再以票證的方式發(fā)回客戶端。在接下來的連接中，客戶端恢復(fù)會話時在 ClientHello 的擴(kuò)展字段 session_ticket 中攜帶加密信息將票證提交回服務(wù)器，由服務(wù)器檢查票證的完整性，解密其內(nèi)容，再使用其中的信息恢復(fù)會話。

這種方法有可能使擴(kuò)展服務(wù)器集群更為簡單，因為如果不使用這種方式，就需要在服務(wù)集群的各個節(jié)點之間同步會話。

Session ticket 需要服務(wù)器和客戶端都支持，屬于一個擴(kuò)展字段，占用服務(wù)器資源很少。

警告
會話票證破壞了 TLS 安全模型。它使用票證密鑰加密的會話狀態(tài)并將其暴露在線路上。有些實現(xiàn)中的票證密鑰可能會比連接使用的密碼要弱。如果票證密鑰被暴露，就可以解密連接上的全部數(shù)據(jù)。因此，使用會話票證時，票證密鑰需要頻繁輪換。文章來源地址http://www.zghlxwxcb.cn/news/detail-763632.html

到了這里，關(guān)于TLS/SSL 詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！