一篇文章告訴你，TLS 1.3 如何用性能為 HTTPS 正名

序?魔戒再現

幾天前，OpenSSL 官方宣布即將發布的新版本 （OpenSSL 1.1.1） 將會提供 TLS 1.3 的支持，而且還會和之前的 1.1.0 版本完全兼容，這當然是個好消息。如果說 HTTP/2 是當前互聯網 Web 發展的討論熱點之一，那么下一個熱點應該就是 TLS 1.3 了。

談到 TLS 那么就不得不說回 HTTPS，2016 年應該算是國內站點使用 HTTPS 激增的一年，從 Google Trend 上也可以看出該關鍵詞的搜索熱度從 2016 年開始飆升。不光如此，所有從事互聯網 Web 技術相關的開發人員，也應該能夠明顯感受到，身邊使用 HTTPS 的網站越來越多了。

為什么近兩年來 HTTPS 被大家更廣泛的應用？

一方面得益于「中國特色」的網絡安全環境，運營商層出不窮的各種劫持給所有的用戶和開發者都上了生動的一課。

用戶每天被來自各種廣告聯盟漫天的牛皮癬廣告和運營商話費余額查詢所包圍。不僅如此，隨著公司流量不斷的被劫持導流到其他地方。搞得很多公司連苦心經營的市場蛋糕都沒辦法安心的吃，終于大部分公司坐不住了。當然***和口誅筆伐是沒有用的，所以擁有業務上擁有 HTTPS 和 HTTP DNS 解決方案，也就順理成章的成了技術公司在偉大防火墻內生存的必備技能之一。

另一方面，從安全角度講，互聯網上通過明文傳輸數據本身就是一件高風險的事情，什么數據泄露、中間人攻擊、用戶被盜號、被競爭對手背后捅刀子 App 下載被劫持.....也是屢見不鮮。

那么說回主題，既然 HTTPS 可以一勞永逸的解決上述問題，而為什么大家之前不盡快的用起來？

問題在于：考慮到 HTTPS 要比 HTTP 更加消耗服務器資源，而且相比于 HTTP 建立連接握手時需要消耗的大量時間影響用戶端的體驗，使得很多人望而卻步，尤其是在移動網絡下。

當然，還有 SSL 證書的成本也要算進去。

王者歸來

在 Web 領域，傳輸延遲（Transmission Latency）是 Web 性能的重要指標之一，低延遲意味著更流暢的頁面加載以及更快的 API 響應速度。而一個完整的 HTTPS 鏈接的建立大概需要以下四步： 第一步：DNS 查詢 瀏覽器在建立鏈接之前，需要將域名轉換為互聯網 IP 地址。一般默認是由你的 ISP DNS提供解析。ISP 通常都會有緩存的，一般來說花費在這部分的時間很少。

第二步：TCP 握手（ 1 RTT） 和服務器建立 TCP 連接，客戶端向服務器發送 SYN 包，服務端返回確認的 ACK 包，這會花費一個往返（1 RTT）

第三步：TLS 握手 （2 RTT） 該部分客戶端會和服務器交換密鑰，同時設置加密鏈接，對于 TLS 1.2 或者更早的版本，這步需要 2 個 RTT

第四步：建立 HTTP 連接（1 RTT） 一旦 TLS 連接建立，瀏覽器就會通過該連接發送加密過的 HTTP 請求。 我們假設 DNS 的查詢時間忽略不計，那么從開始到建立一個完整的 HTTPS 連接大概一共需要 4 個 RTT，如果是瀏覽剛剛已經訪問過的站點的話，通過 TLS 的會話恢復機制，第三步 TLS 握手能夠從 2 RTT 變為 1 RTT。

總結： 建立新連接 ： 4 RTT + DNS 查詢時間 訪問剛瀏覽過的連接： 3 RTT + DNS 查詢時間

在此之前我們需要簡單回顧一下 TLS 1.2 是如何工作的。

TLS 1.2 建立新連接

在一次新的握手流程中，Client Hello 總是客戶端發送的第一條消息，該消息包含客戶端的功能和首選項，與此同時客戶端也會將本身支持的所有密碼套件（Cipher Suite）列表發送過去

Server Hello 將服務器選擇的連接參數傳送回客戶端，同時將證書鏈發送過去，進行服務器的密鑰交換

進行客戶端部分的密鑰交換，此時握手已經完成，加密連接已經可以使用

客戶端建立 HTTP 連接

TLS 1.2 會話恢復

會話恢復： 在一次完整協商的連接斷開時，客戶端和服務器都會將會話的安全參數保留一段時間。希望使用會話恢復的服務器會為會話指定唯一的標識，稱為會話 ID。 1. 希望恢復會話的客戶端將相應的會話 ID 放入 ClientHello 消息中，提交給服務器 2. 服務器如果愿意恢復會話，將相同的會話 ID 放入 Server Hello 消息返回，使用之前協商的主密鑰生成一套新密鑰，切換到加密模式，發送完成信息 3. 客戶端收到會話已恢復的消息，也進行相同的操作，

TLS 1.3 建立新連接

在一次新的握手流程中，客戶端不僅會發送 Client Hello 同時也會將支持的密碼套件以及客戶端密鑰發送給服務端，相比于 TLS1.2，該步驟節約了一個 RTT

服務端發送 Server Hello ，服務端密鑰和證書

客戶端接收服務端發過來的信息，使用服務端密鑰，同時檢查證書完整性，此時加密連接已經建立可以發送 HTTP 請求，整個過程僅僅一個 RTT

TLS 1.3 0-RTT 會話恢復

TLS 1.2 中通過 1 個 RTT 即可完成會話恢復，那么 TLS 1.3 是如何做到 0 RTT 連接的？ 當一個支持 TLS 1.3 的客戶端連接到同樣支持 TLS 1.3 的服務器時， 客戶端會將收到服務器發送過來的 Ticket 通過相關計算，一起組成新的 預共享密鑰，PSK （PreSharedKey）。客戶端會將該 PSK 緩存在本地，在會話恢復時在 Client Hello 上帶上 PSK 擴展，同時通過之前客戶端發送的完成（finished）計算出恢復密鑰 （Resumption Secret）通過該密鑰加密數據發送給服務器。服務器會從會話 Ticket 中算出 PSK，使用它來解密剛才發過來的加密數據。 至此完成了該 0-RTT 會話恢復的過程。

以上簡單描述了 TLS 1.3 建立連接的大致流程，也解釋了為什么 TLS 1.3 相比于之前的 TLS 1.2 會有更出色的性能表現。 當然 TLS 1.3 還有非常非常多的細節以及安全特性，優點以及缺點（去除靜態 RSA 和 DH 密鑰協商、禁止 RC4、有副作用的 0-RTT 握手存在重放攻擊，不支持前向保密.....），限于篇幅并沒有更深入的去探討。

總結

TLS 1.3 將是 Web 性能以及安全的一個新的里程碑，隨之 TLS1.3 帶來的 0-RTT 握手，淡化了大家之前對使用 HTTPS 性能上的隱憂。于此同時，在未來隨著 HTTP/2 的不斷普及，強制性使用 HTTPS 成為了一種必然。

HTTPS 的推廣也離不開一些公益性的組織，比如 Let's Encrypt。

Let's Encrypt 推動了基礎 DV HTTPS 證書的普及，讓互聯網上的中小站長和獨立博客用戶很容易的用上 HTTPS。而對于企業來說，DV 證書是不能滿足要求的。需要信任等級更高、安全級別更強的企業型 SSL 證書（OV SSL）以及增強型SSL證書（EV SSL），相比于 DV 證書，后兩者價格雖會更貴一些，而帶來的安全性保證卻是前者 DV 證書不能相比的。

本文轉載自異步社區。

https

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。