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.3 以及 0-RTT 是如何減少延遲的?

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

TLS 1.2 建立新連接

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

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

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

4.客戶端建立 HTTP 連接

TLS 1.2 會話恢復

會話恢復：

在一次完整協商的連接斷開時，客戶端和伺服器都會將會話的安全參數保留一段時間。希望使用會話恢復的伺服器會為會話指定唯一的標識，稱為會話 ID。

1.希望恢復會話的客戶端將相應的會話 ID 放入 ClientHello 消息中，提交給伺服器

2.伺服器如果願意恢復會話，將相同的會話 ID 放入 Server Hello 消息返回，使用之前協商的主密鑰生成一套新密鑰，切換到加密模式，發送完成信息

3.客戶端收到會話已恢復的消息，也進行相同的操作。

TLS 1.3 建立新連接

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

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

3.客戶端接收服務端發過來的信息，使用服務端密鑰，同時檢查證書完整性，此時加密連接已經建立可以發送 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 證書不能相比的。

* 本文作者：lalalaha，轉載請註明來自FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！