[[192336]]

近日，席卷全球的勒索病毒再次被發現新的變種，新的病毒將利用Windows操作系統中的漏洞，通過加密后的重命名文件來感染計算機，這讓已經平息的風波再起一絲波瀾。

[[192337]]

人們紛紛指責勒索者的無恥行為，竟然利用操作系統漏洞搜刮上百萬美元，但是這些在「中國特色」的網絡安全環境下，也是小巫見大巫了，因為那些運營商層出不窮的各種劫持給所有的用戶和開發者都上了生動的一課。

[[192338]]

用戶每天被來自各種廣告聯盟漫天的牛皮癬廣告和運營商話費余額查詢所包圍。不僅如此，隨著公司流量不斷的被劫持導流到其他地方，搞得很多公司連苦心經營的市場蛋糕都沒辦法安心的吃。

終于大部分公司坐不住了，開始對運營商進行了聲討和口誅筆伐。

當然這些病沒有用的，所以擁有業務上擁有 HTTPS 和 HTTP DNS 解決方案，也就順理成章的成了技術公司在偉大防火墻內生存的必備技能之一。

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

[[192339]]

既然 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。

[[192340]]

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

那么 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 成為了一種必然。