開啓 TLS 1.3 加密協議，極速 HTTPS 體驗

時間 2019-11-12

標籤開啓 tls 1.3 加密協議 https 體驗简体版

原文原文鏈接

隨着互聯網的發展，用戶對網絡速度的要求也愈來愈高，尤爲是目前在大力發展 HTTPS 的狀況下，TLS 加密協議變得相當重要。又拍雲在 HTTPS 的普及和性能優化上，始終作着本身的努力和貢獻。2018年初，又拍雲 CDN 網絡部署了 TLS 1.3，進一步提高了用戶的訪問速度與安全。html

什麼是 TLS 1.3？

TLS 1.3 加密協議是在 TLS 1.0 、TLS 1.1 、TLS 1.2 以前版本基礎上進行的升級和改造，也是迄今爲止改動最大的一次，IETF 正在制定 TLS 1.3 的新標準，目前尚在草案階段，能夠參考最新草案。相比 TLS 1.2 ，TLS 1.3 的主要區別在於：react

新的加密套件只能在 TLS 1.3 中使用，舊的加密套件不能用於 TLS 1.3 鏈接；
添加了0-RTT 模式，在創建鏈接時節省了往返時間（以某些安全性爲代價）；
廢除了靜態的 RSA（不提供前向保密）密鑰交換，密鑰交換機制如今可提供前向保密；
ServerHello 以後的全部握手消息採起了加密操做；
TLS 1.2 版本的重協商握手機制已被棄用，TLS 1.3 中從新協商變爲不可行了；
相比過去的的版本，會話恢復在服務端是無狀態的，使用了新的 PSK 交換；
DSA 證書再也不容許在 TLS 1.3 中使用；

以上的這些改動，能夠避免以前版本出現的缺陷，不只如此，還能夠減小 TLS 握手的時間。總結一下，TLS 1.3 與之前的版本相比具備以下兩個大的優點，分別是：git

更快的訪問速度
加強安全性

TLS 1.3 做用

1. 更快的訪問速度

爲了對比 TLS 1.3 在 TLS 握手階段的變化，這裏將 TLS 1.2 和 TLS 1.3 在 TLS 握手階段進行對比。github

△ TLS 1.2 完整握手框架（來自 RFC 5246 ）算法

從上圖能夠看出，使用 TLS 1.2 須要兩次往返（ 2-RTT ）才能完成握手，而後才能發送請求。chrome

△ TLS 1.3 完整握手框架（來自 TLS 1.3 最新草案）瀏覽器

TLS 1.3 的握手再也不支持靜態的 RSA 密鑰交換，這意味着可使用帶有前向安全的 Diffie-Hellman 進行全面握手。從上圖能夠看出，使用 TLS 1.3 協議只須要一次往返（ 1-RTT ）就能夠完成握手。安全

相比 TLS 1.2 ，TLS 1.3 的握手時間會減半。這意味着訪問一個移動端網站，使用 TLS1.3 協議，可能會減小將近 100ms 的時間。關於 1-RTT 最大的變化是消除了 ServerKeyExchange 和 ClientKeyExchange 消息，DH 參數和公鑰如今以特殊的 key_share 擴展發送，這是一種新的擴展類型，將被包含在 Client Hello 和 Server Hello 消息中。性能優化

△ TLS 1.3 0-RTT 模式握手框架（來自 TLS 1.3 最新草案）網絡

值得關注的是，TLS 1.3 草案中新增了零 RTT （ 0-RTT ）模式，也即在上一次鏈接中，握手完成以後，服務端會發送一條 ServerConfiguration 消息，在隨後的客戶端發起第一個 TLS 記錄 ClientHello 過程當中，直接附加加密的應用程序數據，該模式將會致使更加快速的訪問體驗。

2. 加強的安全性

TLS 的發展有 20 多年的歷史，在以前的版本中，TLS 1.2 是高度可配置的，爲了更好的兼容舊版本的瀏覽器，這意味着那些易受攻擊的站點始終在運行着不安全的加密算法，這讓互聯網黑客有可乘之機。TLS 1.3 在以前版本的基礎上刪除了那些不安全的加密算法，這些加密算法包括：

RSA 密鑰傳輸 —— 不支持前向安全性
CBC 模式密碼 —— 易受 BEAST 和 Lucky 13 攻擊
RC4 流密碼 —— 在 HTTPS 中使用並不安全
SHA-1 哈希函數 —— 建議以 SHA-2 取而代之
任意 Diffie-Hellman 組—— CVE-2016-0701 漏洞
輸出密碼 —— 易受 FREAK 和 LogJam 攻擊

TLS 1.3 目前支持如下加密套件：

TLS13-AES128-GCM-SHA256
TLS13-AES256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES128-CCM-SHA256
TLS13-AES128-CCM-8-SHA256

新的加密套件只能在 TLS 1.3 中使用，舊的套件不能用於 TLS 1.3 鏈接。總之，TLS 1.3 相比老版本的 TLS 協議將會更加安全，這也表明着互聯網安全的一大進步。

2018 年初，又拍雲在 CDN 部分節點中部署了 TLS 1.3，做爲國內較早支持 TLS 1.3 的 CDN 廠商，又拍雲始終跟隨時代的步伐，爲互聯網世界的安全與加速貢獻着本身的一份力量。在互聯網世界這個生態系統中，進行 TLS 安全協議的升級並不簡單，這個須要客戶端和服務端同時進行升級，並確保客戶端和服務端的全部通訊都是正常的。

一鍵開啓 TLS 1.3

1）在又拍雲 CDN 平臺啓用 TLS 1.3

在又拍雲 CDN 控制檯，針對 TLS 1.3 開放了切換開關，TLS 1.3 默認爲關閉狀態，您能夠手動開啓，以下圖所示：

值得聲明的是， CDN 是否啓用 TLS 1.3 ，這個取決於客戶端瀏覽器是否支持，若是客戶端並不支持 TLS 1.3 ，則會進行協議降級，仍會使用較低的 TLS 1.2 協議進行通訊。

2）在瀏覽器中啓用 TLS 1.3

目前最新版本的 Chrome 和 Firefox 都支持 TLS 1.3，可是都須要手動開啓。

在 Firefox 中手動啓用 TLS 1.3

Mozilla Firefox 用戶能夠經過如下方式在 Firefox 中啓用 TLS 1.3 支持（請注意，Firfox Nightly版本默認支持 TLS 1.3，而 Firefox 穩定版（截至日前是 Firfox 57）須要專門配置以支持 TLS 1.3 ）。

在 Firefox 地址欄中輸入 about:config。若是顯示警告屏幕，請確認您要當心，可忽略安全提示；
在搜索區域搜索 security.tls.version.max；
經過雙擊它將首選項的值更改成 4（默認爲 3 ）。

在 Chrome 中手動啓動 TLS 1.3

Google Chrome 用戶能夠經過如下方式在 Chrome 中啓用 TLS 1.3 支持（請注意，Chrome Canary 版本默認支持 TLS 1.3，而 Chrome 穩定版（截至日前是Chrome 64）須要專門配置以支持 TLS 1.3 ）

在瀏覽器的地址欄中加載 chrome://flags/，這將打開 Web 瀏覽器的實驗頁面。
在搜索區域搜索 TLS 或者 tls ，找到 TLS 1.3 選項，默認爲 Default
須要將 TLS 1.3 改成 Enabled (Draft)；
從新啓動 Web 瀏覽器。

注意：Chrome 62 以前的版本須要將 Maximum TLS version enabled 改成 TLS 1.3。

驗證服務端是否支持了 TLS 1.3

使用 Google Chrome 開發者工具，選擇 Security 模塊，以下圖所示，當安全連接爲 TLS 1.3 時，說明這次鏈接是使用 TLS 1.3 進行通訊的。

以上能夠得知，瀏覽器以及服務端都支持 TLS 1.3 纔可使用 TLS 1.3 進行通訊。

總結

TLS 1.3 是 Web 安全與性能的一大進步，雖然主流瀏覽器還未默認開啓，可是這一天的到來不會過久，又拍雲牢牢跟隨時代的步伐，但願爲互聯網用戶提供更安全、更快的加速體驗，爲推動互聯網的發展貢獻本身的力量。與此同時，咱們也很高興成爲國內較早支持 TLS 1.3 功能的 CDN 廠商。