例如，假设以下是一个 IP 在 5 分钟内到两个网站的 HTTPS URL：“A.com/1”、“A.com/2”、“A.com/3”、“B.com/1” ，“B.com/2”。
对数据包的监控会显示：
相关问题： 我的公司可以看到我访问了哪些 HTTPS 站点吗？
虽然这个问题确实有额外的信息，但据我所知，它并没有具体解决“仅显示访问过“A.com/1”和“B.com/1”的 IP 的场景（第一个每个站点的 HTTPS 请求）” - 尽管对此有错误的可能性很高，如果问题重复，我们很乐意删除该问题。
注意：这是发布到的答案的后续问题：为什么 HTTPS 不是默认协议？
TLS 向窃听者透露以下信息：
如果您通过单击一系列链接与网站进行交互，则窃听者可以在每次单击网页时看到其中的每一个。可以结合这些信息来尝试推断您正在访问的页面。
因此，在您的示例中，TLS 仅显示 A.com 与 B.com，因为在您的示例中，URL 的其余部分在所有情况下都是相同的长度。但是，您的示例选择不当：它不代表网络上的典型实践。通常，特定站点上的 URL 长度会有所不同，因此会显示有关您正在访问的 URL 的信息。此外，页面长度和资源数量也有所不同，这揭示了更多信息。
有研究表明，这些泄漏可以向窃听者透露有关您正在访问哪些页面的大量信息。因此，您不应假设TLS 会隐藏您正在访问的页面以防窃听者。（我意识到这是违反直觉的。）
补充：以下是对HTTPS流量分析文献中一些研究的引用：
陈硕，王瑞，王晓峰，张克焕。 Web 应用程序中的侧信道泄漏：今天的现实，明天的挑战，IEEE Security & Privacy 2010。这篇论文相当令人兴奋；例如，它显示了基于 AJAX 的搜索建议如何显示您正在输入的字符，甚至通过 SSL。这是本文的高级概述。
张克焕，周莉，王瑞，王晓峰，陈硕。 Sidebuster：自动检测和量化 Web 应用程序开发中的侧通道泄漏。CCS 2010。
马克·解放者，布赖恩·尼尔·莱文。 推断加密 HTTPS 连接的来源。CCS 2006。
乔治·丹尼兹。基于 TLS 的 HTTP 协议的流量分析，未发布。
George Dean Bissias、Marc Liberatore、Brian Neil Levine。加密 HTTPS 流中的隐私漏洞。宠物 2005。
孙启祥、Daniel R. Simon、王一民、Wilf Russell、Venkata N. Padmanabhan、Lili Qiu。 加密网页浏览流量的统计识别。IEEE 安全与隐私 2002。
安德鲁·欣茨。 使用流量分析对网站进行指纹识别。PET2002。
郑海宁，Ron Avnur。 SSL加密网页浏览流量分析。班级项目，1998 年。
Shailen Mistry，Bhaskaran Raman。 量化加密网络浏览的流量分析。班级项目，1998 年。
第二个选择。大多。
当浏览器访问 HTTPS 网站时，它会建立一个TLS隧道，其中涉及非对称密钥交换（客户端和服务器就共享密钥达成一致）。该密钥交换机制使用服务器公钥，服务器将其显示为证书的一部分。服务器证书包含服务器名称（例如A.com），客户端验证该名称是否与它期望的名称匹配（即 URL 中的服务器名称）。服务器证书是在密钥交换之前发送的，因此很明显。
URL 的其余部分作为 HTTP 请求的一部分发送，该请求发生在加密隧道内，因此对第三方不可见。一个给定的隧道可能会被其他几个 HTTP 请求重用，但是（通过构造）它们都用于同一个服务器（同一个域名）。
这实际上是一个模糊的问题。这就是为什么。当您访问 https 服务器时，http（在这里看到 https 只是 http over TLS）是比运行在下面的 TLS 更高的层。完成的第一件事是协商 TLS 设置，如密码套件、密钥、握手等。这是在 https 端口上完成的，但还没有 http 数据。然后客户端或服务器更改为加密模式，所有内容都被加密。
协商完成后，它转向应用程序数据，它只是普通的旧 http 协议作为有效负载。
但此数据已加密，因此不会显示任何 URL。但是，众所周知，服务器和客户端的 IP 地址没有加密，因为它不是在 TLS 层中使用，而是在低于 TLS 的 IP 层中使用，这是较低级别的。TLS 是 IP 数据包的有效负载，其中包含 IP 地址、端口号、IP 协议（如 tcp 等）作为标头。因此，因为只有 TLS 被加密，所以这些项目没有被加密。
此外，只要服务器和/或客户端的证书可以“链接”到根权限或具有有效证书，窃听就不是问题。
最后我想说的是，TLS 和 HTTPS 实际上是一个框架和算法，用于协商最高安全级别，基于客户端和服务器的偏好以及最低支持的框架。基本上，TLS 没有定义实际使用的加密。这些是密码套件，通常在与 TLS 协议不同的 RFC 类型设置中进行监管。因此，仅基于 HTTPS，仅说明其提供的领域的安全质量是不够的。只能假设一些最低限度的安全性和难度。密码套件的实际质量是一个复杂的问题，并且针对每种类型，因为有许多依赖于完全不同的机制。
编辑 还引起我注意的是，TLS 的服务器名称指示器（用于共享 IP 地址的多个服务器）扩展确实很容易告诉任何人访问的服务器的域名。仅在发送到服务器的第一条消息中，字段将包含域名的 ASCII 文本，例如“google.com”。因此，监视第一个数据包的任何人都可以轻松看到此信息。这是当今许多网站主机中常见的选择。但是任何 URL 都不应该是不安全的。
最后，它真的取决于密码套件，它们并不完全相同，就像没有加密的默认密码套件一样。如果您的浏览器和网站配置为支持这些套装，那么任何人都会看到纯 http。因此，取决于您的 Web 浏览器和服务器，从 IP 地址到 IP 地址以及域名（有时也可以通过其他方式解决，这不太容易），以在其他一些情况下，一切都取决于密码套装的强度。