TL;DR 攻击者无法看到域外的任何内容。

HTTP 请求的结构

HTTP 通过向网站发送两件事来工作：方法和标头。最常见的方法是GET、POST和HEAD，它们分别检索页面、传输数据或仅请求响应标头。TLS 加密整个 HTTP 流量，包括标头和方法。在 HTTP 中，URL 中的路径与标头正文一起发送。以这个例子为例，使用 wget 加载页面foo.example.com/some/page.html。这个文本，作为 ASCII，被发送到服务器：

获取 /some/page.html HTTP/1.1
用户代理：Wget/1.19.1 (linux-gnu)
接受： */*
接受编码：身份
主机：foo.example.com

然后，服务器将使用 HTTP状态代码、它自己的一些标头以及可选的一些数据（例如 HTML）进行响应。例如，给出 301 重定向和一些纯文本作为响应，可能是：

HTTP/1.1 301 永久移动
日期：格林威治标准时间 2017 年 12 月 27 日星期三 04:42:54
服务器：阿帕奇
位置：https://bar.example.com/new/location.html
内容长度：56
内容类型：文本/纯文本

谢谢马里奥，但我们的公主在另一座城堡里！

这会告诉客户正确的位置在其他地方。

这些是通过 TCP 直接发送到站点的标头。TLS 在不同的层上工作，使所有这些都加密。这包括您使用该GET方法访问的页面。请注意，虽然Host标头也在标头正文中并因此加密，但仍可以通过rDNS查找 IP 地址或检查SNI来获取主机，后者以明文形式传输域。

URL 的结构

https://foo.example.com/some/page.html#some-fragment
| 原型 | 域名 | 路径 | 片段 |

• proto - 只有两种常用的协议，HTTP 和 HTTPS。
• domain - 域是example.comand *.example.com，可通过 rDNS 或 SNI 检测到。
• path - 路径完全加密，只能由目标服务器读取。
• 片段- 片段仅对 Web 浏览器可见，不传输。

攻击者可以看到什么

那么，如果您通过 HTTPS 发出请求，攻击者会看到什么？让我们从网络上的被动窃听者的角度来看前面的假设请求。如果我想知道您正在访问什么，我只有有限的选择：

• 我看到您发出一个使用 HTTPS 加密的 Web 请求203.0.113.98。
• 我看到目标端口是 443，我知道它用于 HTTPS。
• 我进行了 rDNS 查找，发现 IP 用于example.com和example.org。
• 我查看了 SNI 记录，发现您正在连接到foo.example.com.

这是我所能做的。如果没有基于发送和接收数据大小的启发式分析（称为流量分析攻击），我将看不到您请求的路径，甚至看不到您使用的方法。对于像维基百科这样的大型服务，仅基于对未加密数据的分析，我不知道您正在查看什么文章。

关于旧浏览器上的引用者的重要说明

即使 HTTPS 对您正在访问的路径进行加密，如果您单击该站点中的超链接，该超链接会转到未加密的页面，则完整路径可能会在referer标题中泄露。许多较新的浏览器不再是这种情况，但旧的或不兼容的浏览器可能仍然有这种行为，将 HTML5 引用元标记设置为始终发送信息的网站也会如此。一个例子发送未加密由客户端从去https://example.com/private/details.html到http://example.org/public/page.html在这种情况下将是：

获取 /public/page.html
参考：https://example.com/private/details.html
用户代理：Wget/1.19.1 (linux-gnu)
接受： */*
接受编码：身份
主机：example.org

因此，从 HTTPS 页面导航到 HTTP 页面可能会泄露前一页面的完整 URL（不包括片段），因此请记住这一点。

天真的答案是否定的：URL 在 TLS 流中加密。但是这个答案忽略了很多相关信息。

假设它是维基百科。假设所有标头字段都相同， https://en.wikipedia.org/wiki/Cryptographyvs的 HTTP GET 请求需要多长时间？https://en.wikipedia.org/wiki/Information_security如果您可以测量可能在单个 TLS 记录中提交的请求的长度，那么您可能可以区分这些。

当然，这并不能帮助您区分对密码学文章的请求和关于编排的文章的请求。如果 TLS 客户端巧妙地向 TLS 记录添加一些被服务器忽略的填充以将其舍入为某个块大小的倍数，这也无济于事。但是英文维基百科关于密码学的文章比关于编排的文章要长得多。因此，即使端点将其 TLS 记录填充到最大 16384 字节，您也可以将有关密码学的文章与有关编排的文章区分开来。

从您作为攻击者的角度来看，有一个复杂的情况：客户端可能对许多请求和许多响应使用相同的 TLS 流。但是，当受害者加载一个嵌入了 CSS、图像、JavaScript等的页面时，它们很可能会全部定时，然后在受害者阅读页面时保持沉默。这些请求的时间和数量提供了另一个变量，您可以在该变量上区分他们正在寻找的页面。

所有这些变量都可以输入到页面的概率模型中——这里有一个例子，取自匿名参考书目。击败一个例子并不意味着网络上的攻击者为一个页面学习的数据分布与另一页面无法区分，只是那个特定的区分器没有那么有效。

那么，作为窃听者，您是否保证能够在线读取 URL？不：它在 TLS 流中被加密（除非选择了 NULL 密码！），所以你最多可以从其他具有概率依赖关系的可观察变量推断它。

另一方面，受害者是否保证他们的 URL 不会被窃听者隐藏？不：有许多变量取决于攻击者可能能够推断出有关的多汁信息的 URL，例如您在梅奥诊所读到的性传播疾病。

（请注意，URL片段#中的任何内容（标记后的部分）https://en.wikipedia.org/wiki/Cryptography#Terminology根本不会在 HTTP GET 请求中传输，除非页面上有一些脚本根据 URL 片段触发不同的网络流量。）

您所说的 URL 位于 HTTP 标头中，这些标头与 HTTP 正文一样，位于 TLS 流中，这意味着它们是加密的。您可以通过在 HTTPS 请求之前嗅探 DNS 请求来获取服务器名称，但您可能无法获得结果，例如，如果名称已经在本地缓存中。

当您使用 TLS 通信方法时，URL 也会被加密。无法通过嗅探安全 HTTPS 流量来找出内容或资源 URL。但安全最佳实践仍然建议不要通过 HTTP 查询字符串发送任何敏感信息。原因是它可以缓存在您的浏览器中或登录您的服务器。