如今，可以检查（解密）组织内部的 TLS (HTTPS) 流量。该机制包括使用在 Web 客户端中配置的根 CA和接收 HTTPS 连接并使用该根 CA 为目的地伪造动态证书的网络设备。因此，对于此 TLS 流量检查，您需要同时控制端点和网络。某些网络设备（例如 IPS、代理和 DLP）实现了这一点。
流量检查有一个商业案例：组织可能希望保护自己免受使用这些加密通道的信息泄漏和恶意软件通信。如果无法进行流量检查，组织就会有一个漏洞被攻击者利用。
但是，我不确定未来以及趋势是什么。例如，我已经阅读了有关证书固定的信息，它试图在某些时候避免流量检查。
未来版本的 TLS 会避免流量检查吗？
现在可以使用这种机制检查所有 HTTPS 流量吗？包括谷歌、苹果、微软……
TLS 本身可以保护两个端点（即客户端和服务器）之间流量的嗅探和修改。TLS拦截只是建立了两个TLS连接，只有一个，即客户端到拦截设备和拦截设备到服务器。这仍然适用于未来的 TLS 版本。
仅当端点的验证未检测到拦截（或明确允许）时，才可能进行 TLS 拦截。如何完成端点的验证不是 TLS 协议本身的一部分，因此对 TLS 协议的更改不会影响这部分。因此，如果不允许拦截，则使用受信任代理 CA 进行 SSL 拦截的当前机制仍将像 SSL pinning 一样工作。请注意，如果证书是由显式添加的 CA 签名的，今天的浏览器将忽略 pinning，这意味着当使用合法的 TLS 拦截时，pinning 将被忽略。但这又是一个验证证书的问题，与 TLS 版本无关。
AFAIK TLS 1.3 草案中没有关于此的内容。而且我认为也没有技术解决方案。如果您允许某人在您的计算机上安装额外的根 CA，那么所有的赌注都将失败。
一些新的研究似乎表明 1.3 确实成功阻止了流量检查：https ://datatracker.ietf.org/doc/html/draft-camwinget-tls-use-cases-00 。自 2015 年以来，规范中的某些内容可能发生了变化？