HSTS 是否保护域免受公开信任的 CA 的侵害,该 CA 已发布非法有效证书?公共信任 CA 的示例是Mozilla CA Bundle的任何成员。
是否有任何方法可以保护域免受非法但受公众信任的 CA 颁发有效证书?
HSTS 是否保护域免受公开信任的 CA 的侵害,该 CA 已发布非法有效证书?公共信任 CA 的示例是Mozilla CA Bundle的任何成员。
是否有任何方法可以保护域免受非法但受公众信任的 CA 颁发有效证书?
不,HSTS 不能防止证书错发。HSTS 只是告诉浏览器只允许通过 HTTPS 连接到该站点,它与检查证书是否应该被信任没有任何关系。
有两件事可以在一定程度上帮助解决问题,证书透明度 (CT) 和证书颁发机构授权 (CAA)。
证书透明度不会阻止 CA 的错误颁发,但它要求证书是公开记录的,因此您可以检查并查看是否为您的域颁发了不应该颁发的证书。自 2018 年以来,Google Chrome 要求所有新颁发的证书都必须经过 CT 记录才能获得信任。不幸的是,Firefox 还没有,但实际上,这些天颁发的所有证书都记录了 CT,否则它们将无法与 Chrome 一起使用。
证书颁发机构授权允许您指示允许哪些 CA 使用 DNS 记录为您的域颁发证书。这将防止 CA 意外发布,但坏演员当然会忽略它。由于 CAA 仅用于说明允许哪些 CA 在特定时间点颁发证书,而不是在证书的生命周期内(即如果 CAA 记录发生更改,证书仍然有效),这只是一个有用的控制对于不是不良行为者的 CA,因为它可以帮助防止他们颁发他们不应该拥有的证书,这最终可能导致他们不被信任。事实上,RFC特别要求浏览器不要检查 CAA 记录。
第三个选项是 HPKP,它允许您固定必须用于您的域的特定证书(它不必是叶证书,固定 CA 的根有点类似于使用 CAA,但更有效),但它已失宠且不再受 Chrome 支持。
编辑:好奇的家伙指出了在某些情况下解决 CT 日志记录的有趣攻击。如果攻击者在中间位置有一个人,他们可能能够在早期判断哪个浏览器正在建立连接(例如,由于 TLS 堆栈中的微小行为差异)。这可以让他们决定不攻击来自已知检查 CT 日志的浏览器的连接,只需将连接转发到合法服务器,但向其他浏览器提供错误颁发且未记录 CT 的证书以冒充合法服务器。似乎防止这种情况的唯一方法是让所有浏览器检查 CT 日志。