本文主要從TLS 1.3的優點、部署和時間發展線介紹了這種用於爲計算機網絡通訊提供安全性的密碼協議TLS。
上篇文章回顧: 淺談DHCP協議
按照維基百科的定義,TLS 是一種用於爲計算機網絡通訊提供安全性的密碼協議,其前身安全套接層(SSL)想必不少人都據說過。TLS 被普遍應用於基於 IP 的網絡協議,如 HTTP、SMTP、FTP 等。最近幾年內,Let's Encrypt 提供的免費證書服務、瀏覽器只對 HTTPS 站點啓用 HTTP/2 和把未使用 HTTPS 而要求輸入密碼的網站標記爲不安全等因素強力推進了 HTTPS 的部署,國際上 HTTPS 的部署率現已超過 50%。在各類因素的推進下,國內站點和應用也在大力推廣 TLS 等密碼協議的使用。html
Figure 1: 數據來自谷歌 Transparency Report,2018年9月14日獲取nginx
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 硬件指令的老設備上能提高加、解密性能。安全
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 標準時工做組針對不少實際測試時出現的問題進行了處理,但咱們部署到線上環境仍是須要注意可能出現的兼容性問題。網絡
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]https://www.ssllabs.com/ssltest/
[2]https://tools.ietf.org/html/rfc8446
[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/
本文首發於公衆號」小米運維「,點擊查看原文。