![Introducing per hostname TLS settings — security fit to your needs](https://blog.cloudflare.com/content/images/2023/08/image1-6.png)
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 高级证书管理器的客户可以在域内的单个主机名上配置 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 端点。
![](https://blog.cloudflare.com/content/images/2023/08/Untitled.png)
从今天开始,所有这些都可以通过 API 端点实现!如果您想进一步了解如何使用我们的按主机名 TLS 设置,请访问我们的开发人员文档。