網絡安全篇，面對復雜多變的網絡環境，我們需要掌握哪些關於網絡安全的相關知識，聊壹聊與網絡安全相關的：HTTPS、SSL、TLS 等。
《 網絡安全 — HTTPS 》
《 網絡安全的基石（上）— 加密 》
《 網絡安全的基石（下）— 完整性與身份認證 》
《 公鑰信任問題 — 數字證書與 CA 》
《 信任始於握手 — TLS 連接過程詳解 》
《TLS 1.3 特性解析》
《 如何優化 HTTPS 連接 》- 待完善
早在 2013 年，IETF（互聯網工程小組） 就對 TLS 1.2 的過時設計和兩次往返開銷心生不滿，因此開始著手準備新版本的 TLS。同年 8 月由 Eirc Rescorla 提議出新版本 TLS 的 功能願望清單 。在經過壹番 辯論 後，最終該提議內容被定義為 TLS 1.3。推動 TLS 1.3 設計的主要問題大概有：
終於在 2018 年 8 月 10 日，歷經 4 年時間，TLS 1.3 最終版本發布了 — RFC-8446 。新的協議使得互聯網變得更快、更安全；隨著 TLS 1.3 的采用率不斷提高，它勢必會長遠影響互聯網的發展；同時盡快將 TLS 1.3 平滑應用到線上環境無疑是勢在必行。
不過在這之前， TLS 1.2 的應用也已經有 10 年（2008 年）的時間了，畢竟歷經了種種考驗，新的協議在推廣和部署上必定會帶來新的挑戰。接下來我們就來看看新版本的 TLS 是如何做的？
由於 TLS 1.1/1.2 等協議已經出現了很多年，很多應用軟件、中間代理（Middlebox）只認老的記錄協議格式，更新改造很困難，甚至僵化。
可部署性
正式由於這些中間代理/軟件（Middlebox）在新的更改中表現不佳，即使是對 TLS 1.3 協議的細微更改（例如消除冗余的 ChangeCipherSpec 消息，版本號從 0x03 升級為 0x04），也最終導致了某些設備的連接失敗問題。這也是 TLS 1.3 從草稿到最終發布花費了這麽長時間的重要原因之壹。
為了保證這些被廣泛部署的“舊設備”能夠繼續使用，TLS 1.3 不得不做出妥協，通過“偽裝”來實現兼容：保持現有的記錄格式不變，使得 TLS 1.3 看上去“像是” TLS 1.2。
擴展協議
那麽，如何區分是 1.2 還是 1.3 呢？
這裏用到壹個新的 擴展協議 （Extension Protocol），它有點“補充條款”的意思，通過在記錄末尾添加壹系列的“擴展字段”來增加新的功能，舊版本的 TLS 不認識它可以直接忽略，這就實現了“向後兼容”。
TLS 1.3 正是利用擴展實現了許多重要的功能，比如 “supported_groups” “key_share” “signature_algorithms” “server_name” 等。
在經歷十余年的實踐中獲得許多寶貴經驗的 TLS 1.2 陸續發現了很多的漏洞和加密算法的弱點。因此消除潛在的危險設計來糾正以前的錯誤成為 TLS 1.3 的設計目標之壹。所以新版本的 TLS 協議裏要修補這些不安全的因素。
例如：
固定密鑰交換
經過這樣壹番“減肥瘦身”之後，TLS 1.3 的密鑰交換算法只有 ECDHE 和 DHE 了，關於橢圓曲線（ECC）也被“砍”到只剩 P-256 和 x25519 等 5 種。
首先來說下廢除 RSA 和 DH 密鑰交換算法的原因：
由於客戶端默認會選擇 ECDHE 而非 RSA 做密鑰交換，這是因為它不具有“ 前向安全 ”（Forward Secrecy）：“假設有人長期記錄了加密的數據，然後在後續的某個時間段獲得了服務器的 RSA 私鑰，那麽黑客就能夠使用該私鑰解密出之前所有報文的 “Pre-Master”，再計算出會話密鑰，破解所有密文。這便是 今日截獲，明日破解 ”
而 ECDHE 算法在每次握手時都會生成壹對臨時公鑰和私鑰，每次通信的秘鑰對都是不同的，也就是“壹次壹密”，即使黑客花大力氣破解了這壹次的會話密鑰，也只是這次通信被攻擊，之前的歷史消息不會受到影響，仍然是安全的。
所以現在主流的服務器和客戶端在握手階段都已經不再使用 RSA，改用 ECDHE，而 TLS 1.3 在協議裏明確廢除了 RSA 和 DH 則在標準層面保證了“前向安全”。
固定密碼
多年以來，密鑰交換機制不是唯壹引起安全漏洞的部分，對稱密鑰部分也有相當壹部分問題。
同樣，用於對稱加密的算法在經過“減肥瘦身”之後也只保留了 AES、ChaCha20 ，分組模式只能用 AEAD 的 GCM、CCM 和 Poly1305，摘要算法也只能用 SHA 256、SHA 384。
這樣原來眾多的加密算法、參數組合導致密碼套件非常復雜，難以選擇。而經過瘦身之後的 TLS 1.3 只剩下 5 個套件，使得客戶端或服務端在選擇密碼套件時變得“更加容易”。然而更重要的是，這些算法在 TLS 長期的實踐過程中先後已經被證實是構成不安全的因素，從而導致安全漏洞。
修復數字簽名
經過前面的學習，相信妳也知道 TLS 另壹個重要部分是身份驗證。在每個連接中服務都是用具有公鑰的數字證書向客戶端提供身份認證。在 RSA 加密模式下，服務器通過解密預主密鑰並通過對話記錄計算 MAC 來證明其對私鑰的所有權。在 Diffie-Hellman 模式下，服務器使用數字簽名來證明私鑰的所有權。
在 TLS 1.2 和更早的版本中，服務器的簽名僅涵蓋部分握手。用於協商使用哪種對稱密碼的部分沒有由私鑰簽名。這也導致許多引人註目的漏洞 FREAK ， LogJam 等。而在 TLS 1.3 由於服務器對整個握手記錄進行簽名，因此可以避免這些情況。
HTTPS 建立連接時除了要做 TCP 握手，還要做 TLS 握手，在 TLS 1.2 中會多花兩個消息往返（2 - RTT），這可能導致幾十毫秒甚至上百毫秒的延遲，在移動網絡中延遲還會更嚴重。
1-RTT 模式
密碼套件的大幅度簡化，也就沒有必要再像以前那樣走復雜的的協商流程了。TLS 1.3 壓縮了以前的 “Hello” 協商過程，刪除了 “Key Exchange” 消息，把握手時間減少到了 “1-RTT”，效率提高了壹倍。
下面是 TLS 1.3 握手過程的簡圖，註意與前面介紹的 TLS 1.2 對比區別在哪裏。
0-RTT 恢復
除了標準的 “1-RTT” 握手，受 QUIC 協議的啟發，客戶端可以在其第壹條消息中將加密的數據發送到服務器，與未加密的 HTTP 相比，沒有額外的延遲成本。
在 TLS 1.2 中，有兩種恢復連接的方法：會話 ID 和會話 Ticket，而 1.3 則將他們組合在壹起形成稱為 PSK（pre-shared key，預***享密鑰）恢復的新模式。
握手分析
目前 Nginx 等 Web 服務器都能夠很好的支持 TLS 1.3，但是要求底層的 OpenSSL 必須是 1.1.1。因此如果要部署需要先升級妳的 OpenSSL 版本。
首先TCP 建立連接之後，瀏覽器首先還是發壹個 “ Client Hello ”。
由於 1.3 的消息要兼容 1.2，所以開頭的版本號、支持的密碼套件和隨機數（Client Random）結構都是壹樣的（這時的隨機數是 32 個字節）。
註意 “Client Hello” 裏的擴展，“ supported_versions ” 表示這是 TLS 1.3，“ supported_groups ” 是支持的曲線，“ key_share ”是曲線對應的參數。
這有點是像是“有話盡量壹口氣說完”，還是按照老規矩進行“打招呼”，我這邊有這些信息，考慮到版本升級，所以附帶了壹些信息，可能後面會用到。
服務器收到 “Client Hello” 同樣返回 “Server Hello” 消息，還是要給出壹個 隨機數 （Server Random）和選定密碼套件。
表面上看 Version 和 TLS 1.2 是壹樣的，重點是後面的擴展。“ supported_versions ” 裏確認使用的是 TLS 1.3，然後在 “ key_share ” 擴展帶上曲線和對應的公鑰參數。
服務器的回應還是老套路，服務端對客戶端的提供的信息作出選擇，另外服務端還要再附加上幾個參數，這次加密就協商定了。
可以看到相比 TLS 1.2 的握手過程，TLS 1.3 僅用兩條消息就***享了 4 個信息： Client Random 和 Server Random 、 Client Params 和 Server Params 。兩邊就可以各自用 DH 算出 “ Pre-Master ”，再用 HKDF 生成主密鑰 “ Master Secret ”，效率比 TLS 1.2 提高了壹大截。
在計算出主密鑰後，服務器立刻發出 “ Change Cipher Spec ” 消息，比 TLS 1.2 提早進入加密通信，後面的證書等就都是加密的了，減少握手時明文信息泄露。
TLS 1.3 還多了壹個 “ Change Cipher Spec ” 消息，服務器用私鑰把前面的曲線、套件、參數等握手數據加了簽名，作用和 “ Finished ” 消息差不多。但由於是私鑰簽名，所以強化了身份認證和防篡改。
兩個“打招呼”消息之後，客戶端驗證服務器證書，再發 “Finished” 消息，就正式完成了握手，開始收發 HTTP 報文。
現在已經有很多網站都支持了 TLS 1.3，例如 GitHub ：
今天我們主要介紹了 TLS 1.3 的壹些新特性，簡單總結下來主要包含下面幾點：
TLS 1.3 涉及的內容很多，有關它的更詳細信息請去參照 RFC-8446 ，關於這部分大家還有哪些要分享的呢？歡迎您的留言或指正。
網絡安全系列專題
擴展閱讀