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 端点。
从今天开始，所有这些都可以通过 API 端点实现！如果您想进一步了解如何使用我们的按主机名 TLS 设置，请访问我们的开发人员文档。