1. TLS/SSL協議格式(一)
TLS/SSL協議實際上是分層的，類似IP/TCP協議；
上圖為一個 TLS Record Layer 包，可用看到其結構為：
Record類型:
TCP包中除了 TLS Record Layer 外，可以看到前面還有部分內容，這是因為按照網路協議七層規范，層次關系為數據鏈路層－》網路層－》傳輸層－》TLS/SSL;
其中數據鏈路層的結構為目的地址＋源地址+類型，對應到圖上：
當 TLS Record Protocol 的ContentType=22時，Body的內容採用 Handshake Protocol ;
Hello request 消息由服務端發送給客戶端，通過客戶端重新開始SSL握手；
消息體為空;
客戶端發送 Client hello 消息開始SSL握手；
Server hello 消息由服務端發送給客戶端，作為 Client hello 的響應；如果服務端無法找到匹配的SSL/TLS版本或CipherSuits,會返回 handshake failure alert ;
服務端發送證書到客戶端，客戶端據此驗證服務端身份；一般而言，該消息緊跟著 Server hello 消息；
證書鏈所佔用的位元組，用3bytes表示；
該消息一般緊接著 Server certificate 消息；該消息並不是必須的，取決於協商出的key交換演算法；如果 Server certificate 並不包含計算premaster的所有參數，則必須發送該消息；
採用如下演算法需要發送 Server certificate 消息:
採用如下演算法不需要發送 Server certificate 消息:
由於目前使用較多的是ECDHE,本文只介紹該格式:
1byte,目前為常量0x03;
該消息是可選的，如果服務端需要驗證客戶端身份，可以通過該消息要求客戶端提供證書;
哈希和簽名演算法列表,從TLS1.2開始，之前版本不存在該欄位；用2bytes存儲演算法列表佔用的位元組數；
每個Algorithm由hash(1byte)+signature(1byte)組成；
和 Server certificate 相同
該消息由客戶端發送到服務端，校驗證書
2. tls1.2安全嗎
是的，屬於安全協議，目前最新版本：TLS1.3
3. TLS安全通信
TLS其實是SSL，可能更正式的說法已經不用SSL了。TLS是一套基於非對稱加密演算法的安全傳輸協議，更嚴格來說，TLS先是通過非對稱加密方式交換對稱加密秘鑰，然後採用對稱加密演算法進行安全傳輸。
非對稱加密是這樣的一把鎖，有兩把鑰匙，任意一把鑰匙可以把鎖鎖上，只有另一把鑰匙才能將鎖打開。這兩把鑰匙是成對的，可以互相解密。其中一把是公開的公鑰，另一把是伺服器持有的私鑰。
任何人都可以用公鑰加密一段消息發送給伺服器，做到安全發送。另一方面，伺服器可以用私鑰加密一段消息，將消息明文和密文發送給接收者，以此證明自己的真實身份，這叫做簽名。當然，現實中，是對消息的摘要進行簽名加密，因為摘要比較小。
TLS的第一步，就是讓發送者持有伺服器的公鑰。通常獲得伺服器公鑰的方式，都是向伺服器進行詢問，然後由伺服器明文發送過來的。為了保證這一步的安全性，確保明文發送過來的公鑰沒有被串改，我們又發明了證書。
證書由伺服器名稱信息和伺服器公鑰組成，然後加上證書簽發機構CA和簽發機構對前面信息的簽名。改用證書機制後，伺服器以明文發送自己的證書信息，使用者用CA的公鑰驗證證書簽名，核對相關的伺服器信息，然後就可以信任伺服器的公鑰了。
至於CA公鑰的傳遞方式，一般是內置的或者通過實體進行傳遞。
一般伺服器是不限制使用者訪問的，所以伺服器配置了證書和私鑰，讓發送者能夠安全的從第一步開始建立加密通信機制。即使使用者不驗證伺服器證書，TLS仍舊是以加密方式進行，雖然安全度不是最高，但是屏蔽掉無聊的阿貓阿狗訪問已經足夠了。
更進一步，伺服器可以配置雙向認證，配置CA證書並要求認證使用者的證書。那麼使用者在訪問前就要配置由CA簽發的個人證書和私鑰，在第一步開始時把自己的證書和隨機簽名發過去讓伺服器進行認證。
使用雙向認證的時候，通信的安全性已經足夠高了：消息是加密的，並且不太容易在某個環節被串改，而使用者必須經過伺服器用自己的CA簽發授權證書後才能訪問服務。
TLS的運用其實應該非常廣，只要不是內網服務，而是向不安全的互聯網公開的服務，並且在通信上沒有使用任何加密手段，也沒有特別有效的客戶鑒權，都應該使用TLS。
比如有時候因為某種原因，不得不向互聯網暴露mysql，redis或者其他開源軟體的服務埠，這種大作死的行為，軟體自帶的脆弱的客戶鑒權機制就跟雜草一樣一踩就倒，已經是業界人盡皆知的情形。
如果能為這些開放的服務埠加上TLS雙向認證通信，基本能把侵害排除99%了吧。那如何給這些服務增加TLS安全通信呢？
首先， 把公開的服務改成內網服務 。
第二， 在伺服器和客戶端之間配置TLS tunnel ，通過tunnel轉發客戶端和伺服器之間流量。有很多TLS tunnel客戶端可以使用，這種方式也不會對原系統造成任何改動，所謂各司其職。
4. 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 需要伺服器和客戶端都支持，屬於一個擴展欄位，佔用伺服器資源很少。
5. Go 實現 TLS 雙向認證
將會在 config 文件夾中生成 ca.key 和 ca.crt 文件
將會在 config 文件夾中生成 server.key 、 server.csr 和 server.crt 文件
簽名方式： SHA-256 ，默認的 SHA-1 簽名演算法安全性不夠高，Go 中會出現警告。
將會在 config 文件夾中生成 client.key 、 client.csr 和 client.crt 文件
簽名方式： SHA-256 ，默認的 SHA-1 簽名演算法安全性不夠高，Go 中會出現警告。
wireshark 截圖如下:
6. TLS/SSL數字證書里的指紋演算法、簽名演算法和簽名哈希演算法各是做什麼用的
簽名哈希演算法
當用公鑰解密出數據後，通過簽名哈希演算法計算出傳輸內容的hash值，同時比對隨內容一起傳過來的hash值，確定傳輸內容是否被篡改
簽名演算法
傳遞信息的hash指紋是加密後隨內容一起傳遞的，這為了防止不會好意的人同時修改信息內容和其中的hash值，達到相匹配，讓簽名哈希演算法步驟失去真正作用。所以hash值發出前都需要加密，這是為了數據傳輸更安全上的一道保險鎖。
簽名演算法就是為了解密被加密的傳遞信息的hash指紋
指紋演算法
簡單來講就是驗證收到的數字證書本身有沒有問題。
通過指紋演算法計算證書hash值（指紋），和證書中給出的指紋比對，確認證書正確。