为什么要使用CAA?
CA始终使用以下方法 域验证 确保每个SSL /TLS 证书申请被授权(通常通过确保使用该域以某种方式将其链接到特定站点)。
例如,CA可能会向请求者提供特殊的验证文件。 将该文件放置在网站上可证明请求者也控制了该网站,但不能保证 合法 该控件。 掌握了网站控制权的黑客可能会伪装成合法所有者,然后可以请求并接收SSL /TLS 通过任何CA标准检查的证书,因此 似乎 合法。 然后,他们可以转身使用该SSL /TLS 该网站或其他地方的恶作剧证明。
CAA通过定义允许哪些CA颁发域证书(甚至完全限制证书颁发)来帮助阻止这种利用。 这限制了劫机者可能造成的损害-即使他们控制了某个网站,但他们对恶意SSL /TLS 证书。
CAA如何运作
CAA使用DNS
特 域名系统 (DNS)是Internet基础结构的关键部分。 任何域的所有者都维护DNS记录(在所谓的内部 区域文件),将其域名指向托管其网站的IP地址,然后输入 google.com 进入浏览器窗口而不是 216.58.194.46.
DNS记录通常用作“ Internet电话簿”,但是DNS还允许其他类型的特殊记录,这些特殊记录可以将其他信息分配给域名。
CAA记录
CAA使用一种特殊的记录,称为 证书颁发机构授权资源记录 (CAA记录)。 这些都是使用DNS发布的,域所有者只需将CAA记录添加到他的其他DNS记录中即可。 CAA记录包括 行李牌 和 折扣值,并且标记值对称为“ a” 财产。 还设有一个 旗 指示此属性的重要性。 这是一个什么样子:
example.com。 CAA 0问题“ ssl.com”
在这里, example.com 是该记录适用的域,CAA让我们知道这是哪种记录。 的 0 是标志(默认为零-我们将在下面讨论)。 标签是 问题 并且该值(用引号引起)是 ssl.com,它们共同构成了物业。
旗
标志目前只有两个严格定义的状态: 0 (非关键)和 1 (危急)。 严重标志告诉CA 必须 完全了解该属性标签以继续。 RFC 6844留给用户定义标志使用其他可能性(我们还将在下面讨论这些可能性)。
标签
RFC 6844定义了三个通用标签的使用: 问题, 发行狂 和 碘定义。 (与标志一样,它允许其他潜在的自定义标签类型。)
特 问题 行李牌
特 问题 标签指定授权哪个(如果有)CA颁发该域的证书。 例如,域example.com的所有者可以使用以下DNS区域文件将证书颁发限制为一个CA(在此为SSL.com):
example.com。 CAA 0问题“ ssl.com”
域所有者可以选择为一个域设置多个区域文件:
example.com。 CAA 0问题“ ssl.com” example.com。 CAA 0问题“ comodoca.com”
以上记录限制了SSL /TLS 签发证书 example.com 到两个CA(SSL.com和Comodo.com)。
特 问题 记录还授权命名的CA为指定域的任何子域颁发证书。 因此,允许SSL.com的记录可以允许为 example.com 以及诸如 www.example.com, 邮箱.example.com 甚至是特殊的通配符子域 * .example.com.
CAA记录可用于 限制 证书发行也是如此–该记录告诉使用CAA的证书颁发机构 没有 SSL /TLS 证书应签发 example.com 和子域 任何 CA:
example.com。 CAA 0问题“;”
(本例中的分号表示“这里什么都不允许“,但正如我们稍后将展示的,它也用于定义自定义参数。)
请注意,除非由…修改,否则标准发行标签允许CA颁发通配符证书。
特 发行狂 行李牌
此标记指定授权CA颁发所有者域的通配符证书(即 * .example.com).
通配符是一种通用的子域,在颁发通配符证书时应特别注意。 的 发行狂 标签使域所有者可以定义哪些CA可以与主域或其他子域分开颁发通配符证书。 发行狂 标签优先于任何 问题 标签。 他们使用与 问题 标签。 一些例子:
example.com。 CAA 0问题“ ssl.com” example.com。 CAA 0 issuewild“;”
以上内容允许SSL.com颁发证书以用于 example.com 以及所有子域 除 通配符 * .example.com。 (不允许SSL.com或任何其他CA颁发通配符证书用于 example.com.)
example.com。 CAA 0问题“;” example.com。 CAA 0 issuewild“ ssl.com”
这个例子禁止 所有 CA颁发证书给 example.com 及其子域,但创建了一个例外,以允许SSL.com颁发通配符证书(和 仅由 通配符证书) example.com.
特 碘定义 行李牌
第三个定义的标签是 碘定义。 此标签可用于向域所有者报告无效的证书请求,它们看起来像这样:
example.com。 CAA 0 iodef“ mailto:certissues@example.com” example.com。 CAA 0 iodef“ certissues.example.com”
最上面的记录提供了向该地址发送电子邮件通知所需的CA信息 certissues@example.com。 第二个命令指示CA将事件消息发布到Web服务(由域所有者为此目的设置),网址为 certissues.example.com。 (可以使用这两种方法中的一种或两种,这取决于CA和域所有者如何设置其操作。)
碘定义 帖子使用一种称为 事件对象描述交换格式 或IODEF –因此得名。 (IODEF在 RFC 6546.)
CA定义的标志和标签
RFC 6844中描述的CAA仅专门定义了两个标志状态(0和1)和三个标签(问题, 发行狂 和 碘定义)。 但是,它使设计足够开放,以便CA创建并利用自定义标签和标志来定义其证书颁发过程。 例如:
example.com。 CAA 0问题“ SSL.com; policy = ev”
该记录使用标准 问题 标签带有额外的参数,该参数指示CA在为此域颁发证书时使用其扩展验证(EV)策略。
example.com。 CAA 128 pca“ PCA = 12345”
域所有者可以将此记录与新的CA定义一起使用 PCA 标签以显示他们拥有“首选客户帐户”,并将帐号设置为参数。 (该标志也可以是一个自定义值,最多可以为255。)根据CA设置帐户的方式,这可能允许特定的计费方式,额外的帐户定义的验证或其他特殊处理。
利与弊
加号...
这是使用CAA的几个极好的理由。 CAA的主要和最重要的优势是可以大大降低证书错误签发的风险。 这有助于保护您的域,您的业务和您的在线身份。 可能在特定CA的软件中发现错误的潜在攻击者无法利用它为您的域颁发SSL证书。 此外,使用iodef标记可以让您在尝试利用时获得报告。
CAA的设计提高了安全性,但也可以允许对资源进行更详细的分配-例如,公司可以设置记录,以允许(或限制)销售和营销部门从指定来源购买用于sales.example.com的SSL证书。
另外,CAA提供了极大的灵活性。 对于域所有者,它使用由自己控制的DNS资源记录,并且可以根据需要进行更改,因此它们不绑定到特定的CA(并且可以授权多个CA授予任何给定域名的问题记录) 。 对于CA,即使是自定义用途,CA / B论坛(为CA和浏览器安全问题设定标准的小组)新采用的规则也可以使CAA记录用于验证目的,这是使用它们的另一个很好的理由。
……和缺点
CAA的最大问题是尚未被所有CA所采用。 CA / B论坛的基线要求(所有受信任的CA都满足)要求CA在其在线文档中指定其支持CAA的程度。 但是,在撰写本文时,仅使用CAA 建议,不是必需的。 仍然可以锁定不符合CAA的证书颁发机构,并且在广泛使用CAA之前,劫机者可能会找到愿意颁发恶意证书的不兼容CA。
一个相关的缺点是,即使放置了CAA记录,用户也无法 执行 由证书颁发机构使用。 CA必须符合RFC 6844才能执行这些记录,而不符合要求的CA可能会简单地忽略域所有者在其CAA记录中声明的明确意愿。
域所有者和CA也必须正确配置CAA。 让我们最近加密(确实支持CAA) 报告了其代码库的一个小问题 不幸的是,这导致CAA规则被忽略,并误发了六份证书。 这些都不是恶意异常(对于让我们加密团队在发现后数小时内解决和报告该问题,我们深表感谢)。 但是,这强调了一个合规的证书颁发机构 必须 实施CAA 完美无瑕.
另一个潜在的问题是CAA对DNS的依赖。 除非域所有者保护其名称服务安全,否则这可能是攻击的载体。 RFC 6844建议实施 域名系统安全扩展(DNSSEC),它使用经过数字签名的DNS记录来认证数据并应对DNS欺骗的威胁。
最后,即使适当地实施了CAA并正确实施了CAA记录,也无法完全阻止发行恶意证书。 尽管CAA是限制攻击者选择的有用且重要的工具,但是具有足够访问权限的劫机者(例如,通过控制DNS或通过社会工程)可以绕过它。
结论
证书颁发机构授权作为更广泛的安全生态系统的一部分具有巨大的潜力,CAA的广泛采用和实施将防止证书的错误签发。 不幸的是,目前并非所有的证书颁发机构都支持CAA,但正在讨论如何对所有CA提出更强的建议性或强制性。 尽管仅靠CAA并不能阻止所有证书的错误签发,但这是朝正确方向迈出的良好一步,SSL.com希望敦促您考虑自己使用CAA记录。
参考资料
- RFC6844:DNS证书颁发机构授权(CAA)资源记录
- RFC5070:事件对象描述交换格式
- RFC6546:通过HTTP /传输实时网络间防御(RID)消息TLS
- RFC4033:DNS安全性介绍和要求
- CA / B论坛投票125 – CAA记录
- 有关DNS证书颁发机构授权的维基百科条目