本文主要從TLS 1.3的優勢、部署和時間發展線介紹了這種用於為計算機網路通訊提供安全性的密碼協議TLS。

TLS簡介

按照維基百科的定義，TLS 是一種用於為計算機網路通訊提供安全性的密碼協議，其前身安全套接層（SSL）想必很多人都聽說過。TLS 被廣泛應用於基於 IP 的網路協議，如 HTTP、SMTP、FTP 等。最近幾年內，Let's Encrypt 提供的免費證書服務、瀏覽器只對 HTTPS 站點啟用 HTTP/2 和把未使用 HTTPS 而要求輸入密碼的網站標記為不安全等因素強力推動了 HTTPS 的部署，國際上 HTTPS 的部署率現已超過 50%。在各種因素的推動下，國內站點和應用也在大力推廣 TLS 等密碼協議的使用。

淺談 TLS 1.3

Figure 1: 資料來自谷歌 Transparency Report，2018年9月14日獲取

TLS 1.3的優勢

安全保護

TLS 1.3 移除了很多過時的密碼學原型和功能（例如壓縮、重協商），強制要求完美前向安全。TLS 1.2 支援了很多加密演算法（包括 3DES、靜態 DH 等），這導致了 FREAK、Logjam、Sweet32 等攻擊的出現。TLS 1.3 縮緊了對加密原型的限制，避免了因伺服器啟用不安全的演算法導致協議的安全性受到影響。在這方面的簡化也使得運維和開發者配置 TLS 變得更容易，不再容易誤用不安全的配置。

TLS 1.3 之前，整個握手環節都是沒有加密保護的，這洩漏了很多資訊，包括客戶端和伺服器的身份。TLS 1.3 對握手的絕大部分資訊進行了加密，這保護了使用者隱私，也在一定程度上防止了協議僵化問題。

效能提升

雖然電腦越變越快，但在網際網路上傳輸資料耗費的時間依然受限於光速，所以兩個節點間來回傳輸一次的時間（RTT）成為了限制協議效能的因素之一。TLS 1.3 只需要一個 RTT 就能完成握手，相比 TLS 1.2 省去了一個 RTT。並且 TLS 1.3 支援 “0-RTT” 模式，在該模式下客戶端可以在握手的同時傳送資料，極大地加快了頁面的載入速度。TLS 1.3 還增加了 ChaCha20/Poly1305 支援，在不支援 AES 硬體指令的老裝置上能提升加、解密效能。

淺談 TLS 1.3

TLS 1.3的部署

Tengine 2.2.2 / nginx 1.13.0 提供了 TLS 1.3 支援，和 OpenSSL 1.1.1 配合即可將網站升級到 TLS 1.3。在配置檔案裡將 TLSv1.3 加到 ssl_protocols 中就可以啟用 TLS 1.3 支援了。Qualys 的 SSL 伺服器測試[1]是很方便的 TLS 配置測試工具，可以很方便地檢測公網站點的 TLS 配置及其安全性。

協議僵化問題

當一個網際網路協議長時間不發生變化時，基於該協議開發的裝置就可能無視其預留的變通手段而對其特性作出超出標準的假設，這就是協議僵化現象。在 TLS 1.3 的完善過程中，新的協議因協議僵化問題而不得不模擬老協議的一些行為，這大大拖慢了 TLS 1.3 標準化的進度。儘管在制定 TLS 1.3 標準時工作組針對很多實際測試時出現的問題進行了處理，但我們部署到線上環境還是需要注意可能出現的相容性問題。

TLS 1.3發展時間線

2017年4月25日，nginx 1.13.0 釋出，增加了 TLS 1.3 支援。
2018年3月21日，IESG 批准了 TLS 1.3 草案。
2018年4月17日，Chrome 66 預設開啟了對 TLS 1.3 草案的支援。
2018年5月9日，Firefox 60 預設開啟了對 TLS 1.3 草案的支援。
2018年8月10日，IETF 釋出了 TLS 1.3 標準。
2018年9月11日，OpenSSL 1.1.1 (LTS) 版本釋出，提供 TLS 1.3 支援。TLS 1.3 超過 TLS 1.0 成為 Cloudflare 上使用率排名第二的 TLS 版本。
2018年10月16日，Chrome 70 支援 TLS 1.3 正式標準。
2018年10月23日，Firefox 63 支援 TLS 1.3 正式標準。

參考資料

[1]

[2]

[3]https://en.wikipedia.org/wiki/Transport_Layer_Security

[4]https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/

[5]https://ietf.org/blog/tls13/

[6]https://kinsta.com/blog/tls-1-3/

淺談 TLS 1.3

淺談 TLS 1.3

相關文章