更好地理解 TLS/SSL 备用名称?

更好地理解 TLS/SSL 备用名称?

有人能向 5 岁的孩子解释一下备用名称的用法吗?为什么有些域名有这么多备用名称?

在此处输入图片描述

所有这些域名都共享一个证书吗?使用备用名称是否存在安全风险(MitM 攻击?)?

答案1

TLDR:这就是 Cloudflare

首先,请注意 X.509 证书可以包含两种不同的扩展,主题备用名称和颁发者备用名称。实际上,没有人使用 IssuerAltNames,而您复制的 SSLLabs 报告仅显示 SubjectAltNames,现在几乎每个人都在使用,浏览器(最近)也开始要求

使用此证书的服务器是CloudFlare网络的一部分。云Flare是(主要)所谓的“内容分发网络”,这意味着它们运行网络服务器,最初处理来自浏览器等的 WWW 请求,很多其客户拥有的网站/域名。引用他们的常见问题解答:

Cloudflare 如何工作?
Cloudflare 保护并加速任何在线网站。一旦您的网站成为 Cloudflare 社区的一部分,其网络流量就会通过我们的智能全球网络进行路由。我们会自动优化您的网页交付,以便您的访问者获得最快的页面加载时间和最佳性能。我们还会阻止威胁并限制滥用机器人和爬虫浪费您的带宽和服务器资源。

根据他们的主页,他们目前使用全球 115 个数据中心处理 600 万个“属性”(可能是域名)。为此,他们在每台服务器上处理多个域名(否则他们需要的服务器数量将超过任何人的承受能力),默认证书反映了这一点,尽管他们提供专用证书,但需额外收费

使用共享服务器可能存在风险:如果 CloudFlare 出现错误或失误,则会影响受影响服务器处理的所有网站,这种情况已经出现过一些(请参阅维基百科文章)。但是,由于他们的主要业务和全职工作是运行这些服务器,因此 CloudFlare 服务器的配置和监控可能比大多数(我猜至少 90%)由域所有者直接运行的原始服务器更好,并且在出现问题时可以更快地进行修补。

使用共享证书不会带来任何重大的额外风险,因为任何查看受影响域的 DNS 解析的人都可以看到它们通过 CloudFlare 进行解析——并且所有较新的软件都支持 SAN,因此极少数在使用 SAN 证书连接到服务器时遇到问题的客户端可能已经被攻破。(不要将此与 WindowsXP 和早期的 Android 和 Java6 (!) 等不太古老的软件无法支持服务器名称指示(又称 SNI)相混淆,与 TLS 相关但不同的功能

请注意,如果单个企业拥有并使用多个域名,即使是“内部”网络服务器仍可能使用相当多的 SubjectAltName 条目,例如:

  • (非通配符)子域名,例如 www.bigcorp.com sales.bigcorp.com support.bigcorp.com 或
  • 不同 TLD 中的相同或相似名称,如 www.bigcorp.co.uk www.bigcorp.co.jp 或
  • 明显不同的名称,如 www.bigpreviousname.com www.bigbrandslogan.com 等等。

答案2

在我们拥有主题备用名称(SAN)扩展,证书只能有一个“通用名称”。客户端使用此通用名称来证实他们正在交谈的服务是他们期望交谈的服务,而不是恶意的、虚假的或配置错误的服务。

尤其是对于网站而言,许多网站都希望拥有多个客户端可用来连接的名称(www.example.com、example.com、example.net、www.example.co.uk、example.tv)。但为每个可能的名称获取证书是一项负担。此外,早期版本的 SSL 和 TLS 协议要求每个证书都托管在唯一的 IP/端口组合上,这增加了额外的成本和配置工作量。

SAN 扩展允许将多个附加标识符(不仅仅是 DNS 名称)与单个证书关联。对于上述两个问题,这可以节省大量时间和成本。具有多个名称的单个站点现在可以使用单个证书,该证书包含 Web 服务器上具有单个 IP/端口组合的所有名称。

即使对于位于终止 TLS 连接的公共负载平衡器或反向代理后面的不同站点,SAN 证书也很有用。这在内容分发网络(CDN)喜欢云Flare或者阿卡迈。这也是为什么您可能会在野外发现带有大量看似不相关的 SAN 条目的证书。

回答您的其他问题:

所有这些域名都共享一个证书吗?

是的

使用备用名称是否存在安全风险(MitM 攻击?)?

没有具体的安全使用 SAN 证书的风险。它们与非 SAN 证书一样值得信赖。但是,有人可能会说,您有“把鸡蛋放在一个篮子里”的正常风险。该证书出现问题会影响使用它的所有站点。

相关内容