一篇文章告訴你，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 建立新連線
- 在一次新的握手流程中，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 證書不能相比的。 
廣告時間：
SSL 證書是 HTTPS 中必不可少的一步，七牛雲也於近日上線了一站式 SSL 證書申購服務，為更多的網際網路企業以及個人開發者提供證書服務，也有為個人站長及開發者推出免費單域名 DV SSL 證書。