在過去的五年中，網際網路工程任務組（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為新協議制定了一份功能願望清單：
經過一番辯論後，決定將這個新版本的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攻擊利用了兩件事：
1、許多瀏覽器和伺服器仍然支援20世紀90年代故意弱密碼（稱為匯出密碼）的事實，
2、以及用於協商使用哪種密碼的握手部分未經數字簽名的事實。
這些攻擊被稱為降級攻擊，它們允許攻擊者強制兩個參與者使用雙方支援的最弱密碼，即使支援更安全的密碼也是如此。 在這種攻擊方式中，犯罪者處於握手的中間，並將從客戶端通告的伺服器支援的密碼列表更改為僅包含弱匯出密碼。 然後，伺服器選擇一個弱密碼，攻擊者通過暴力攻擊計算出金鑰，允許攻擊者在握手時偽造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中國】