[[192336]]

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

[[192337]]

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

[[192338]]

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

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

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

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

[[192339]]

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

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

當(dāng)然，還有 SSL 證書的成本也要算進去。

在 Web 領(lǐng)域，傳輸延遲(Transmission Latency)是 Web 性能的重要指標(biāo)之一，低延遲意味著更流暢的頁面加載以及更快的 API 響應(yīng)速度。而一個完整的 HTTPS 鏈接的建立大概需要以下四步：

第一步：DNS 查詢

瀏覽器在建立鏈接之前，需要將域名轉(zhuǎn)換為互聯(lián)網(wǎng) IP 地址。一般默認是由你的 ISP DNS提供解析。ISP 通常都會有緩存的，一般來說花費在這部分的時間很少。

第二步：TCP 握手( 1 RTT)

和服務(wù)器建立 TCP 連接，客戶端向服務(wù)器發(fā)送 SYN 包，服務(wù)端返回確認的 ACK 包，這會花費一個往返(1 RTT)

第三步：TLS 握手 (2 RTT)

該部分客戶端會和服務(wù)器交換密鑰，同時設(shè)置加密鏈接，對于 TLS 1.2 或者更早的版本，這步需要 2 個 RTT

第四步：建立 HTTP 連接(1 RTT)

一旦 TLS 連接建立，瀏覽器就會通過該連接發(fā)送加密過的 HTTP 請求。

我們假設(shè) DNS 的查詢時間忽略不計，那么從開始到建立一個完整的 HTTPS 連接大概一共需要 4 個 RTT。

[[192340]]

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

那么 TLS 1.3 以及 0-RTT 是能減少延遲嗎?先來看一下 TLS 1.2 是如何工作的。

TLS 1.2 建立新連接

1. 在一次新的握手流程中，Client Hello 總是客戶端發(fā)送的第一條消息，該消息包含客戶端的功能和首選項，與此同時客戶端也會將本身支持的所有密碼套件(Cipher Suite)列表發(fā)送過去
2. Server Hello 將服務(wù)器選擇的連接參數(shù)傳送回客戶端，同時將證書鏈發(fā)送過去，進行服務(wù)器的密鑰交換
3. 進行客戶端部分的密鑰交換，此時握手已經(jīng)完成，加密連接已經(jīng)可以使用
4. 客戶端建立 HTTP 連接

TLS 1.2 會話恢復(fù)

會話恢復(fù)：

在一次完整協(xié)商的連接斷開時，客戶端和服務(wù)器都會將會話的安全參數(shù)保留一段時間。希望使用會話恢復(fù)的服務(wù)器會為會話指定唯一的標(biāo)識，稱為會話 ID。

1. 希望恢復(fù)會話的客戶端將相應(yīng)的會話 ID 放入 ClientHello 消息中，提交給服務(wù)器
2. 服務(wù)器如果愿意恢復(fù)會話，將相同的會話 ID 放入 Server Hello 消息返回，使用之前協(xié)商的主密鑰生成一套新密鑰，切換到加密模式，發(fā)送完成信息
3. 客戶端收到會話已恢復(fù)的消息，也進行相同的操作

終于進入重頭戲，TLS 1.3 如何建立連接呢?

1. 在一次新的握手流程中，客戶端不僅會發(fā)送 Client Hello 同時也會將支持的密碼套件以及客戶端密鑰發(fā)送給服務(wù)端，相比于上個版本 TLS1.2，該步驟已經(jīng)節(jié)約了一個 RTT
2. 服務(wù)端發(fā)送 Server Hello ，服務(wù)端密鑰和證書
3. 客戶端接收服務(wù)端發(fā)過來的信息，使用服務(wù)端密鑰，同時檢查證書完整性，此時加密連接已經(jīng)建立可以發(fā)送 HTTP 請求，整個過程僅僅一個 RTT

TLS 1.3 0-RTT 會話恢復(fù)

TLS 1.2 中通過 1 個 RTT 即可完成會話恢復(fù)，那么 TLS 1.3 是如何做到 0 RTT 連接的?

當(dāng)一個支持 TLS 1.3 的客戶端連接到同樣支持 TLS 1.3 的服務(wù)器時， 客戶端會將收到服務(wù)器發(fā)送過來的 Ticket 通過相關(guān)計算，一起組成新的 預(yù)共享密鑰，PSK (PreSharedKey)?？蛻舳藭⒃?PSK 緩存在本地，在會話恢復(fù)時在 Client Hello 上帶上 PSK 擴展，同時通過之前客戶端發(fā)送的完成(finished)計算出恢復(fù)密鑰 (Resumption Secret)通過該密鑰加密數(shù)據(jù)發(fā)送給服務(wù)器。服務(wù)器會從會話 Ticket 中算出 PSK，使用它來解密剛才發(fā)過來的加密數(shù)據(jù)。

至此完成了該 0-RTT 會話恢復(fù)的過程。

以上簡單描述了 TLS 1.3 建立連接的大致流程，也解釋了為什么 TLS 1.3 相比于之前的 TLS 1.2 會有更出色的性能表現(xiàn)。

當(dāng)然 TLS 1.3 還有非常非常多的細節(jié)以及安全特性，優(yōu)點以及缺點(去除靜態(tài) RSA 和 DH 密鑰協(xié)商、禁止 RC4、有副作用的 0-RTT 握手存在重放攻擊，不支持前向保密.....)，限于篇幅并沒有更深入的去探討。

總結(jié)

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