Cloudflare 的目標之一是為我們的客戶提供必要的控制手段，以適合他們需求的方式實現安全性。在 SSL/TLS 領域，我們提供兩個關鍵控制：設定最低 TLS 版本，以及限制支援的密碼套件清單。以前，這些設定套用至整個網域，導致「全有或全無」的效果。雖然在整個網域中擁有統一的設定對於某些使用者來說是理想的選擇，但對於有不同子網域需求的使用者來說，有時缺乏必要的精細度。
因此，我們非常高興地宣佈，從今天起，客戶將可以按主機名稱設定 TLS。
使用現代通訊協定的權衡
在理想情況下，每個網域都可以更新為使用最安全、最現代的通訊協定，而不會出現任何問題。遺憾的是，情況並非如此。新的標準和通訊協定需要得到採納才能有效。2018 年 4 月，IETF 對 TLS 1.3 進行了標準化。它移除了 TLS 1.2 所支援的易受攻擊的加密演算法，並透過只需要一次往返（而不是兩次）來提高效能。使用者要從 TLS 1.3 中受益，其瀏覽器或裝置必須支援新的 TLS 版本。對於現代瀏覽器和裝置來說，這不是問題——這些作業系統可以動態更新，以支援新通訊協定。但是，傳統用戶端和裝置顯然不是以同樣的思維方式構建的。在 2015 年之前，新通訊協定和標準的開發歷時數十年，而不是數月或數年，因此用戶端在交付時只支援一種標準，即當時使用的標準。
如果我們查看 Cloudflare Radar，就會發現約 62.9% 的流量使用 TLS 1.3。這對於一個 5 年前才標準化的通訊協定來說已經是相當大的數量。但這也意味著，網際網路上仍有很大一部分流量在使用 TLS 1.2 或更低版本。
數位簽章演算法也是如此。用於 TLS 的 ECDSA 於 2006 年標準化，比 RSA 晚了好幾年。它提供比 RSA 更高的安全層級，使用的金鑰長度更短，從而提高了每次請求的效能。要使用 ECDSA，網域擁有者需要獲取並提供 ECDSA 憑證，連接的用戶端需要支援使用橢圓曲線加密法 (ECC) 的密碼套件。雖然大多數受公眾信任的憑證授權單位現在都支援基於 ECDSA 的憑證，但由於採用速度緩慢，許多舊版系統只支援 RSA，這意味著限制為僅支援 ECC 型演算法的應用程式可能會阻止使用舊版用戶端和裝置的使用者存取。
權衡利弊
在安全性和可存取性方面，找到適合企業的中間點非常重要。
為維護品牌，大多數公司將其所有資產部署在一個網域下。根網域（如 example.com）通常用作行銷網站，提供有關公司、公司使命、產品和服務的資訊。然後，在同一網域下，可能會有公司部落格（如 blog.example.com）、管理入口網站（如 dash.example.com）和 API 閘道（如 API.example.com）。
行銷網站和部落格類似，都是靜態網站，不收集存取使用者的資訊。另一方面，管理入口網站和 API 閘道會收集和呈現需要保護的敏感性資料。
在考慮部署哪些設定時，您需要考慮交換的資料和使用者群。行銷網站和部落格應面向所有使用者。您可以為支援現代通訊協定的用戶端設定現代通訊協定，但不一定要限制舊裝置使用者對這些網頁的存取。
管理入口網站和 API 閘道的設定方式應能為所交換的資料提供最佳保護。這意味著放棄支援存在已知漏洞的不太安全的標準，並要求使用新的安全通訊協定。
要實現這種設定，您需要能夠為網域內的每個子網域單獨進行設定。
按主機名稱 TLS 設定——現在可用！
使用 Cloudflare Advanced Certificate Manager 的客戶可以在網域內的單個主機名稱上配置 TLS 設定。客戶可以使用它來啟用 HTTP/2，或在特定主機名稱上設定最小 TLS 版本和支援的密碼套件。套用至特定主機名稱的任何設定都將優先於區域級設定。新功能還允許您對主機名稱及其萬用字元記錄進行不同的設定；這意味著您可以將 example.com 配置為使用一種設定，而將 *.example.com 配置為使用另一種設定。
假設您希望網域的預設最低 TLS 版本為 TLS 1.2，但對於儀表板和 API 子網域，您希望將最低 TLS 版本設定為 TLS 1.3。在 Cloudflare 儀表板中，您可以將區域層級最低 TLS 版本設定為 1.2，如下所示。然後，要為儀表板和 API 子網域設定最低 TLS 版本為 TLS 1.3，請透過特定主機名稱和設定呼叫按主機名稱 TLS 設定 API 端點。
從今天開始，所有這些都可以透過 API 端點實現！如果您想進一步瞭解如何使用我們的按主機名稱 TLS 設定，請存取我們的開發人員文件。