当我们实施新的安全解决方案时，我遇到了这个问题。所述解决方案拥有自己的根 CA 证书，并将“即时”为 HTTPS 网页创建证书。您访问的每个 HTTPS 页面现在都有一个由安全解决方案的 CA 颁发的“即时”证书，而不是其原始证书。
您现在所做的基本上是与充当代理的安全解决方案进行通信。它“打开” TLS 流量，对其进行检查，然后（重新）建立与目标 Web 服务器的加密连接。
现在，如果它不是一个安全解决方案，而是一个恶意行为者这样做呢？这将是一种非常简单方便的方式来执行中间人攻击。在浏览器中安装 CA 证书真的是安全 TLS 连接和 MITM 噩梦之间唯一的事情吗？
我们有几种（失败的？）机制可能会阻止这种情况，例如 DANE 或 DNS CAA，但看起来，现代浏览器实际上并没有使用这些机制。
有没有办法（在 2022 年）阻止某人创建 TLS 证书并以 DANE 或 DNS CAA 应该做的方式冒充另一方？我说的是实际上阻止客户端连接到提供错误证书的服务器，而不仅仅是像 Certificate Transparency 那样监控颁发。
您所描述的是企业防火墙或防病毒检查 HTTPS 流量的正常方式。默认情况下，浏览器会阻止对这些站点的访问，用户不应点击这些警告。相反，代理的 CA 需要以受信任的形式导入浏览器/系统，这通常在公司环境中或安装本地防病毒产品时自动完成。
有没有办法（在 2022 年）阻止某人仅仅创建 TLS 证书并冒充另一方......
无法阻止其他人创建由大多数用户不信任的 CA 签名的任意证书。只有这样的证书不会被理智的客户信任，因此这里没有需要解决的实际风险。
由明确受信方进行的 SSL 拦截反而服务于公认的目的。虽然它破坏了端到端的安全性并因此降低了安全性，但它通过进行内容检查以防止恶意软件等提供了实际的安全优势。并且它不允许任意攻击者成为中间人，因为这样的攻击者没有访问受信任的 CA 证书。
在浏览器中安装 CA 证书真的是安全 TLS 连接和 MITM 噩梦之间唯一的事情吗？
在浏览器（或浏览器使用的操作系统级信任存储）中安装 CA 证书是最终信任。这意味着“如果此证书的持有人证明我正在与 foo.com 交谈，那么我正在与 foo.com 交谈”。是的，这使该证书的持有者可以对 MITM 进行一切操作——但仅限于信任该证书的设备。为了以这种方式 MITM 某人，您要么必须充分控制他们的设备以在其信任存储中安装您的证书，要么颠覆每个人默认信任的大牌 CA 之一。
[推论：你绝对没有工作用笔记本电脑的任何隐私。不要用它来阅读您的个人邮件、检查您的银行余额或其他任何事情。]