我想你在问：

如果该页面https://host1/包含<iframe>加载https://host2/，这是否意味着与host1的 HTTPS 连接以某种方式包装与host2的连接？

不。虽然认为如果一个页面在视觉上包含另一个页面似乎很自然，那么底层连接可能会发生类似的事情，但事实并非如此。

您的浏览器创建到host1和host2的不同 HTTPS 连接，并且两者以（或多或少）相同的方式。因此，如果您在单独的选项卡或窗口中打开它们，主机名会泄漏给网络上的窃听者，如果将另一个加载到框架中，同样适用。事实上，两个 TLS 连接的观察者很难判断流量是否代表<iframe>关系中的两个文档，或者用户只是先打开https://host1/然后被重定向到https://host2/.

通过 HTML 框架嵌套浏览上下文的概念存在于应用层，并且大部分独立于浏览器保护数据传输的方式。

在大多数情况下，能够被动检查流量的中间人可以找出所有访问站点的主机名。这是因为此信息包含在与此站点的 TLS 握手中，特别server_name是 ClientHello的扩展名（SNI - 服务器名称指示）。

如果直接访问其他站点或使用 iframe 访问其他站点，则无关紧要，即 iframe 流量不会在与父站点的现有 TLS 连接内加密。用户是否登录到父站点也无关紧要。

这有一些例外。如果 SNI 被加密，自然无法检测到名称，即ESNI。但在这种情况下，攻击者至少会知道目标站点的 IP 地址，这可能有助于确定这可能是哪个域。

除此之外，HTTP/2 还有一些鲜为人知的特性，称为连接合并。在这种情况下，可以通过单个 HTTP/2 连接访问不同的域，只要两个域解析到相同的 IP 地址并由单个证书覆盖。但是，只有第一个域出现在 TLS 握手的 SNI 中，而另一个域对被动攻击者是隐藏的。攻击者甚至无法检测到访问了不同的域，它所看到的只是到特定 IP 地址的加密流量。

主机名在任何 TLS 上下文中都不是私有的，句号。

@mentallurg 的答案是正确的，但它并不像简单地由父框架定义子框架那么明显，因为第三方脚本包含的所有父框架在不知情的情况下添加的所有父框架都无处不在，这样的脚本随后将获取其他资源并创建子框架。

这就是通过自己包含谷歌标签管理器（GTM）的方式，它将获取其他脚本，如谷歌分析（gapi），当它加载到父框架中时，它也会去获取更多脚本以最终包含一个脚本，该脚本将创建一个 iframe并使用 iframe 上下文来存储秘密（实际上它不是秘密，也许隐藏是一个更好的词）令牌。

因此，如果您认为 iframe 在您不知情或未同意的情况下实现，则需要追溯 iframe 的包含，因为正如@mentallurg 所说，您确实决定包含它并在某个时候实际包含它。

我想知道观察未加密流量的人会看到什么

整个页面，所有框架，都在端点上。

TLS 将保护线路上的数据，但旨在让端点能够查看 TLS 通信的明文内容。即页面和所有框架都是端点，并且可以轻松访问端点可以访问的所有数据，以访问端点本身的给定保护。

您可以使用属性限制 iframe 权限sandbox，如果您创建了 iframe，这是最好的，因为之后添加它是无效的。您还可以发送X-Frame-Options和Content-Security-Policy标头来控制第三方创建的 iframe 的行为。

但是由于您在评论中不断回到主机名问题，我想重复一个简单的事实；主机名永远不是私有的