Cloutflare：TLS 1.3解讀 你想了解的都在這兒

在過去的五年中，互聯網工程任務組（IETF），即定義互聯網協議的標準機構，一直致力於標準化其最重要的安全協議之一的最新版本：傳輸層安全性（TLS）。 TLS用於保護Web（以及更多！），提供加密並確保每一個HTTPS網站和API的真實性。 最新版本的TLS，TLS 1.3（RFC 8446）於本月10日發佈。 這是該協議的第一次重大改革，帶來了重大的安全性和性能改進。 本文轉載自Cloudflare博客，深刻探討了TLS 1.3中引入的變化及其對互聯網安全將來的影響。

一場變革

Cloudflare提供安全性的一個主要方式是支持網站和API等Web服務的HTTPS。使用HTTPS（「S」表明安全），瀏覽器和服務器之間的通訊經過加密和通過身份驗證的通道傳輸。經過HTTPS而不是HTTP提供內容可讓訪問者確信他們看到的內容是由合法內容全部者呈現的，而且通訊是安全的，不會被竊聽。在這個世界裏，在線隱私比以往任什麼時候候都更加劇要，這是一個大問題。

使HTTPS安全的引擎下的機制是一種稱爲TLS的協議。它源於九十年代中期在Netscape開發的稱爲安全套接字層（SSL）的協議。到20世紀90年代末，Netscape將SSL交給IETF，IETF將其重命名爲TLS，並今後成爲該協議的管理者。許多人仍將Web加密稱爲SSL，即便絕大多數服務已切換到僅支持TLS。 SSL這個術語繼續受到人們的歡迎，而Cloudflare經過無鑰匙SSL和通用SSL等產品名稱使這個術語保持活力。

在IETF中，協議稱爲RFC。 TLS 1.0是RFC 2246，TLS 1.1是RFC 4346，TLS 1.2是RFC 5246.今天，TLS 1.3發佈爲RFC 8446. RFC一般按順序發佈，保留46做爲RFC編號的一部分是一個很好的延續。

在過去幾年中，TLS已經被發現諸多的問題。 首先，實現TLS的代碼存在問題，包括Heartbleed，BERserk，goto fail;等等。 這些問題不是協議的基礎，並且主要是因爲缺少測試。 像TLS Attacker和Project Wycheproof這樣的工具備助於提升TLS實施的穩健性，但TLS面臨的更具挑戰性的問題與協議自己有關。

TLS由工程師使用數學家的工具設計。 SSL時代的許多早期設計決策都是使用啓發式方法和對如何設計健壯的安全協議的不徹底理解。 也就是說，這不是協議設計者（Paul Kocher，Phil Karlton，Alan Freier，Tim Dierks，Christopher Allen等人）的錯，由於整個行業仍在學習如何正確地作到這一點。 在設計TLS時，關於安全認證協議設計的正式論文，如Hugo Krawczyk的標誌性SIGMA論文，還須要幾年的時間。 TLS是90年代的密碼：它當時意味着很好，看起來很酷，可是現代密碼學家的調色板已經發展得不一樣了。

許多設計缺陷是使用形式驗證發現的。 學者們試圖證實TLS的某些安全屬性，但卻找到了反例，這些反例被轉化爲真正的漏洞。 這些弱點包括純理論（SLOTH和CurveSwap），高資源攻擊者（WeakDH，LogJam，FREAK，SWEET32），既「實用」又「危險」（POODLE，ROBOT）。

TLS 1.2實在是太慢了

加密在網上一直很重要，但從歷史上看，它只用於登陸或發送信用卡信息，使大多數其餘數據暴露。 在過去幾年中，一直存在一個主要趨勢，即將HTTPS用於互聯網上的全部流量。雖然可以保護更多咱們在線上的交互，但卻使鏈接變得更慢了。

要使瀏覽器和Web服務器就密鑰達成一致，他們須要交換加密數據。 自TLS於1999年標準化以來，在TLS中稱爲「握手」的交換基本保持不變。握手須要在發送加密數據以前在瀏覽器和服務器之間再進行兩次往返（或者在恢復先前鏈接時進行一次往返））。 與單獨的HTTP相比，HTTPS的TLS握手的額外成本致使潛在的顯着命中。 這種額外的延遲會對以性能爲中心的應用產生負面影響。

定義TLS 1.3

IETF對TLS 1.2的過期設計和兩次往返開銷不滿意，開始着手定義新版本的TLS。 2013年8月，Eric Rescorla爲新協議制定了一份功能願望清單：

www.ietf.org/proceedings…

通過一番辯論後，決定將這個新版本的TLS稱爲TLS 1.3。 推進TLS 1.3設計的主要問題與五年前提出的主要問題大體相同：

● 減小握手延遲

● 加密更多的握手

● 提升跨協議攻擊的彈性

● 刪除舊功能

該規範由志願者經過開放的設計過程塑造，通過四年的勤奮工做和激烈的辯論，TLS 1.3如今處於最終形式：RFC 8446.隨着採用的增長，新協議將使互聯網更快、更安全。

下文將重點介紹TLS 1.3與之前版本相比的兩個主要優點：安全性和性能。

在過去的二十年中，咱們已經學到了不少關於如何編寫安全加密協議的知識。 從POODLE到Lucky13到SLOTH到LogJam的巧妙命名攻擊代表了，即便是TLS 1.2也包含了加密設計早期的陳舊觀點。 TLS 1.3的設計目標之一是經過消除潛在危險的設計元素來糾正之前的錯誤。

修復密鑰交換

TLS是所謂的「混合」密碼系統。這意味着它使用對稱密鑰加密（加密和解密密鑰相同）和公鑰加密（加密和解密密鑰不一樣）。混合方案是Internet上使用的主要加密形式，用於SSH，IPsec，Signal，WireGuard和其餘協議。在混合密碼系統中，公鑰密碼術用於在雙方之間創建共享密鑰，共享密鑰用於建立可用於加密交換數據的對稱密鑰。

根據經驗，公鑰加密是緩慢且昂貴的（每一個操做幾微秒到幾毫秒），對稱密鑰加密快速且便宜（每一個操做納秒）。混合加密方案容許您經過僅執行一次昂貴的部分，以極少的開銷發送大量加密數據。 TLS 1.3中的大部分工做都是關於改進握手的部分，其中公鑰用於創建對稱密鑰。

RSA密鑰交換

TLS的公鑰部分是關於創建共享祕密。 使用公鑰加密有兩種主要方法。 更簡單的方法是使用公鑰加密：一方用另外一方的公鑰加密共享密鑰併發送它。 而後另外一方使用其私鑰解密共享祕密而且......原來他們都有一樣的祕密。 這種技術於1977年由Rivest，Shamir和Adelman發現，稱爲RSA密鑰交換。 在TLS的RSA密鑰交換中，共享密鑰由客戶端決定，而後客戶端將其加密到服務器的公鑰（從證書中提取）並將其發送到服務器。

TLS中提供的另外一種密鑰交換形式是基於另外一種形式的公鑰密碼術，由Diffie和Hellman於1976年發明，即所謂的Diffie-Hellman密鑰協議。 在Diffie-Hellman中，客戶端和服務器都從建立公鑰 - 私鑰對開始。 而後，他們將其關鍵份額的公共部分發送給另外一方。 當每一方收到另外一方的公鑰共享時，他們將其與他們本身的私鑰組合在一塊兒，最終獲得相同的值：前主祕密。 而後，服務器使用數字簽名來確保交換未被篡改。 若是客戶端和服務器都爲每一個交換選擇一個新的密鑰對，則該密鑰交換稱爲「臨時交換」。

兩種模式都會致使客戶端和服務器具備共享密鑰，但RSA模式有一個嚴重的缺點：它不是前瞻性的。這意味着若是有人記錄加密的對話，而後得到服務器的RSA私鑰，他們就能夠解密對話。這甚至適用於記錄對話而且密鑰在將來一段時間內得到的狀況。在一個國家政府正在記錄加密對話並使用像Heartbleed這樣的漏洞來竊取私鑰的世界中，這是一個至關現實的威脅。

RSA密鑰交換在一段時間內一直存在問題，且不只僅是由於它不是前向保密的。1998年，Daniel Bleichenbacher在SSL中進行RSA加密的方式發現了一個漏洞並建立了所謂的「百萬消息攻擊」，它容許攻擊者經過發送一百萬或者一個服務器的私鑰來執行RSA私鑰操做。 如此精心設計的消息，並尋找返回的錯誤代碼的差別。 多年來，這種攻擊獲得了改進，在某些狀況下只須要數千條消息便能從一臺普通筆記本電腦發動攻擊。最近發現，主要網站（包括facebook.com）在2017年也容易受到Bleichenbacher攻擊變種的影響，稱爲ROBOT攻擊。

爲了下降非前向祕密鏈接和百萬郵件攻擊所帶來的風險，RSA加密已從TLS 1.3中刪除，將短暫的Diffie-Hellman做爲惟一的密鑰交換機制。 刪除RSA密鑰交換帶來了其餘優點，咱們將在下面的性能部分中討論。

以Diffie-Hellman命名的加密手段

在加密方面，提供太多選項會致使選擇錯誤的選項。 在選擇Diffie-Hellman參數時，這個原理最爲明顯。 在之前版本的TLS中，Diffie-Hellman參數的選擇取決於參與者。 這致使一些實現選擇不正確，致使部署易受攻擊的實現。 TLS 1.3取消了這一選擇。

Diffie-Hellman是一個功能強大的工具，但並不是全部Diffie-Hellman參數均可以「安全」使用。 Diffie-Hellman的安全性取決於稱爲離散對數問題的特定數學問題的難度。 若是能夠解決一組參數的離散對數問題，則能夠提取私鑰並破壞協議的安全性。 通常來講，使用的數字越大，解決離散對數問題就越困難。 所以，若是您選擇較小的DH參數，則會遇到麻煩。

2015年的LogJam和WeakDH攻擊代表，許多TLS服務器可能被欺騙使用Diffie-Hellman的小數字，容許攻擊者破壞協議的安全性並解密對話。

Diffie-Hellman還要求參數具備某些其餘數學屬性。 2016年，Antonio Sanso在OpenSSL中發現了一個問題，其中選擇的參數缺少正確的數學屬性，致使另外一個漏洞。

TLS 1.3採用固定路由，將Diffie-Hellman參數限制爲已知安全的參數。 可是，它仍然有幾個選擇; 只容許一個選項使得在之後發現這些參數不安全的狀況下更新TLS很是困難。

混合加密方案的另外一半是數據的實際加密。 這是經過組合認證碼和對稱密碼來完成的，每一個參與方都知道密鑰。 正如我將要描述的，有許多方法能夠加密數據，其中大多數都是錯誤的。

CBC模式密碼

在上一節中，咱們將TLS描述爲混合加密方案，具備公鑰部分和對稱密鑰部分。 公鑰部分並非多年來形成麻煩的惟一部分。 對稱關鍵部分也有其公平的問題。 在任何安全通訊方案中，您都須要加密（保密）和完整性（以確保人們不會修改，添加或刪除對話的部分）。 對稱密鑰加密用於提供加密和完整性，但在TLS 1.2及更早版本中，這兩個部分以錯誤的方式組合，致使安全漏洞。

執行對稱加密和解密的算法稱爲對稱密碼。 對稱密碼一般有兩種主要形式：分組密碼和流密碼。

流密碼採用固定大小的密鑰並使用它來建立任意長度的僞隨機數據流，稱爲密鑰流。 要使用流密碼進行加密，您能夠經過將密鑰流的每一個位與消息的相應位進行異或來獲取消息並將其與密鑰流合併。要解密，請使用加密消息並使用密鑰流對其進行異或。 純流密碼的示例是RC4和ChaCha20。 流密碼很受歡迎，由於它們易於實現且軟件速度快。

分組密碼與流密碼不一樣，由於它只加密固定大小的消息。 若是要加密比塊大小更短或更長的消息，則必須執行一些操做。 對於較短的消息，您必須在消息的末尾添加一些額外的數據。 對於較長的消息，您能夠將消息拆分爲密碼能夠加密的塊，而後使用分組密碼模式以某種方式將各個部分組合在一塊兒。 或者，您能夠經過使用塊密碼加密計數器序列並將其用做流來將塊密碼轉換爲流密碼。 這稱爲「計數器模式」。 使用分組密碼加密任意長度數據的一種流行方式是稱爲密碼塊連接（CBC）的模式。

爲了防止人們篡改數據，加密是不夠的。 數據還須要受到完整性保護。 對於CBC模式密碼，這是使用稱爲消息驗證代碼（MAC）的東西來完成的，這相似於帶有密鑰的花哨校驗和。 密碼強的MAC具備如下特性：除非您知道密鑰，不然找到與輸入匹配的MAC值幾乎是不可能的。 有兩種方法能夠組合MAC和CBC模式密碼。 您先加密，而後加密密文，或者首先MAC明文，而後加密整個文件。 在TLS中，他們選擇後者，MAC-then-Encrypt，結果證實是錯誤的選擇。

你能夠將這個選擇歸咎於BEAST，以及一系列填充oracle漏洞，例如Lucky 13和Lucky Microseconds。CBC模式和填充之間的交互也是SSLv3中普遍宣傳的POODLE漏洞和TLS的一些實現的緣由。

RC4是由Ron Rivest（RSA的「R」）設計的經典流密碼，自TLS早期就獲得普遍支持。 在2013年，它被發現具備可衡量的誤差，能夠利用它來容許攻擊者解密消息。

在TLS 1.3，全部麻煩的密碼和密碼模式已被刪除。 您不能再使用CBC模式密碼或不安全的流密碼，如RC4。 TLS 1.3中容許的惟一類型的對稱加密是一種稱爲AEAD（帶有附加數據的通過身份驗證的加密）的新結構，它將加密和完整性結合到一個無縫操做中。

修復數字簽名

TLS的另外一個重要部分是身份驗證。 在每一個鏈接中，服務器使用具備公鑰的數字證書向客戶端驗證自身。 在RSA加密模式中，服務器經過解密預主密鑰並在會話的記錄上計算MAC來證實其對私鑰的全部權。 在Diffie-Hellman模式下，服務器使用數字簽名證實私鑰的全部權。 若是你到目前爲止都讀得很仔細，應該很容易猜到這也是錯誤的。

PKCS＃1v1.5

Daniel Bleichenbacher致力於識別TLS中RSA的問題。 2006年，他設計了針對TLS中使用的RSA簽名的紙筆攻擊。 後來發現包括NSS和OpenSSL在內的主要TLS實施容易受到這種攻擊。 此問題再次與正確實現填充的難度有關，在這種狀況下，RSA簽名中使用的PKCS＃1 v1.5填充。 在TLS 1.3中，刪除了PKCS＃1 v1.5以支持更新的設計RSA-PSS。

簽署整個握手記錄

咱們以前描述過服務器如何使用數字簽名來證實密鑰交換沒有被篡改。 在TLS 1.2及更早版本中，服務器的簽名僅涵蓋部分握手。 握手的其餘部分，特別是用於協商使用哪一個對稱密碼的部分，不禁私鑰簽名。 相反，使用對稱MAC來確保握手未被篡改。 這種疏忽致使了許多備受矚目的漏洞（FREAK，LogJam等）。 在TLS 1.3中，這些被阻止，由於服務器簽署整個握手記錄。

FREAK，LogJam和CurveSwap攻擊利用了兩件事：

一、許多瀏覽器和服務器仍然支持20世紀90年代故意弱密碼（稱爲導出密碼）的事實，

二、以及用於協商使用哪一種密碼的握手部分未經數字簽名的事實。

這些攻擊被稱爲降級攻擊，它們容許攻擊者強制兩個參與者使用雙方支持的最弱密碼，即便支持更安全的密碼也是如此。 在這種攻擊方式中，犯罪者處於握手的中間，並將從客戶端通告的服務器支持的密碼列表更改成僅包含弱導出密碼。 而後，服務器選擇一個弱密碼，攻擊者經過暴力攻擊計算出密鑰，容許攻擊者在握手時僞造MAC。 在TLS 1.3中，這種類型的降級攻擊是不可能的，由於服務器如今簽署了整個握手，包括密碼協商。

用簡化來改善性能

TLS 1.3是一個更加優雅和安全的協議，刪除了上面列出的不安全功能。 這種對衝修剪容許簡化協議，使其更容易理解，更快。

在之前版本的TLS中，主要的協商機制是密碼組。 密碼套件幾乎涵蓋了能夠就鏈接進行協商的全部內容：

● 支持的證書類型

● 用於導出密鑰的散列函數（例如，SHA1，SHA256，...）

● MAC功能（例如，HMAC與SHA1，SHA256，...）

● 密鑰交換算法（例如，RSA，ECDHE，......）

● 密碼（例如，AES，RC4，......）

● 密碼模式（若是適用）（例如，CBC）

先前版本的TLS中的密碼套已經發展成爲巨大的字母湯。 經常使用密碼套件的示例是：DHE-RC4-MD5或ECDHE-ECDSA-AES-GCM-SHA256。 每一個密碼套件由一個名爲Internet Assigned Numbers Authority（IANA）的組織維護的表中的代碼點表示。 每次引入新密碼時，都須要將一組新的組合添加到列表中。 這致使代碼點的組合爆炸，表明着參數的每個有效選擇。

TLS 1.3刪除了許多這些遺留功能，容許在三個正交協商之間進行完全拆分：

● 密碼+ HKDF哈希

● 密鑰交換

● 簽名算法

這種簡化的密碼套件協商和從根本上減小的協商參數集開闢了一種新的可能性。 這種可能性使得TLS 1.3握手延遲從兩次往返降至僅一次往返，從而提供性能提高，確保TLS 1.3受歡迎並普遍採用。

創建與以前沒有見過的服務器的新鏈接時，須要兩次往返才能在鏈接上發送數據。 這在服務器和客戶端在地理位置上彼此靠近的位置並非特別明顯，可是它能夠在移動網絡上產生很大的差別，其中延遲能夠高達200ms，這對人來講是顯而易見的。

1-RTT模式

TLS 1.3如今具備更簡單的密碼協商模型和一組減小的密鑰協商選項（沒有RSA，沒有用戶定義的DH參數）。 這意味着每一個鏈接都將使用基於DH的密鑰協議，而且服務器支持的參數很容易猜想（ECDHE使用X25519或P-256）。 因爲這種有限的選擇，客戶端能夠簡單地選擇在第一條消息中發送DH密鑰共享，而不是等到服務器確認它願意支持哪些密鑰共享。 這樣，服務器能夠學習共享密鑰並提早一次往返發送加密數據。 例如，Chrome的TLS 1.3實現會在第一條消息中向服務器發送X25519密鑰共享。

在極少數狀況下，服務器不支持客戶端發送的密鑰共享之一，服務器能夠發送新消 HelloRetryRequest，讓客戶端知道它支持哪些組。 因爲列表已被削減太多，預計這種狀況不常發生。

0-RTT恢復

QUIC協議啓發了進一步的優化。 它容許客戶端將第一條消息中的加密數據發送到服務器，與未加密的HTTP相比，不會產生額外的延遲成本。 這是一大進步，一旦TLS 1.3被普遍部署，加密的網絡確定比之前更加快捷。

在TLS 1.2中，有兩種方法能夠恢復鏈接，會話ID和會話票證。 在TLS 1.3中，這些被組合以造成稱爲PSK（預共享密鑰）恢復的新模式。 該想法是在創建會話以後，客戶端和服務器能夠導出稱爲「恢復主密鑰」的共享祕密。 這可使用id（會話ID樣式）存儲在服務器上，也能夠經過僅爲服務器知道的密鑰（會話票據樣式）加密。 此會話票證將發送到客戶端並在恢復鏈接時進行兌換。

對於恢復的鏈接，雙方共享恢復主密鑰，所以除了提供前向保密以外，不須要密鑰交換。 下次客戶端鏈接到服務器時，它能夠從上一個會話中獲取祕密並使用它來加密應用程序數據以及會話票證發送到服務器。

0-RTT數據中沒有交互性。 它由客戶端發送，並由服務器使用，沒有任何交互。 這對性能頗有幫助，但須要付出代價：可重複性。 若是攻擊者捕獲發送到服務器的0-RTT數據包，他們能夠重播它，而且服務器有可能接受它爲有效。 這會產生有趣的負面後果。

危險重放數據的一個示例是在服務器上更改狀態的任何內容。 若是增長計數器，執行數據庫事務或執行任何具備永久效果的操做，將其放入0-RTT數據中是有風險的。

做爲客戶端，您能夠嘗試經過僅將「安全」請求放入0-RTT數據來防止這種狀況。 在此上下文中，「安全」表示請求不會更改服務器狀態。 在HTTP中，不一樣的方法應該具備不一樣的語義。 HTTP GET請求應該是安全的，所以瀏覽器一般只能經過在0-RTT中發送GET請求來保護HTTPS服務器免受重放攻擊。 因爲大多數頁面加載以GET「/」開頭，所以頁面加載時間更快。

當在0-RTT中發送的數據用於狀態改變請求時，問題開始發生。 爲幫助防止此故障狀況，TLS 1.3還包括會話票證中的通過時間值。 若是這種狀況發生太大分歧，客戶端要麼接近光速，要麼重播值。 在任何一種狀況下，服務器都應該謹慎拒絕0-RTT數據。

可部署性

TLS 1.3與TLS 1.2及更早版本徹底不一樣，但爲了普遍部署，它必須向後兼容現有軟件。 TLS 1.3從草案到最終發佈花了這麼長時間的緣由之一是，一些現有的軟件（即中間盒）與新的更改並無很好地協調。 即便在線上可見的TLS 1.3協議的微小更改（例如消除冗餘的ChangeCipherSpec消息，將版本從0x0303提高到0x0304）最終致使某些人的鏈接問題。

儘管將來的靈活性已經內置到TLS規範中，可是一些實現對如何處理將來的TLS版本作出了錯誤的假設。形成這種變化的現象稱爲骨化， 爲了適應這些變化，TLS 1.3被修改成看起來很像TLS 1.2會話恢復（至少在線路上）。 這致使了更多功能性但不太美觀的協議，也是您在線升級最普遍部署的協議之一所付出的代價。

結語

TLS 1.3是一種現代安全協議，使用正式分析等現代工具構建，保持其向後兼容性。 它已通過普遍測試，並在使用現實世界部署數據時進行了迭代。 它是一種更清晰，更快速，更安全的協議，能夠在線成爲事實上的雙方加密協議。

發佈TLS 1.3是一項巨大的成就。也是近日行業裏最好的示例，它證實了經過修改20年前部署的遺留代碼來改善人們互聯網體驗，是一件多麼棒的事！TLS 1.3在過去三年中一直處於爭論和分析中，如今已準備好迎接它的黃金時段。 歡迎你，RFC 8446！

【來自SSL中國】