从许多帖子中，我知道 HTTPS 或 SSL 连接中的几乎所有内容都是加密的。不过，我想知道，如果打开连接的计算机位于家庭网络上并且可以访问包括基于 Unix 的路由器操作系统的 wifi 路由器，是否有可能从这种连接中获取 URL？
我不是在谈论任何消息的内容，而只是在浏览器中访问的域以及可能的其余 URL，例如domain.com/thiscategory/site123.
-
2启动 Wireshark，试试看，看看！或者，在此处查看答案：stackoverflow.com/questions/499591/are-https-urls-encrypted– 鲍勃布朗2017 年 12 月 27 日 0:34
-
1不，这是不可能的。– 卢克公园2017 年 12 月 27 日 0:51
-
1欺骗security.stackexchange.com/questions/117536 /... security.stackexchange.com/questions/7705 /... security.stackexchange.com/questions/34794 /...以及其他几个链接。– 戴夫汤普森 0852017 年 12 月 27 日 3:47
-
1TLS 加密“它”之上的所有内容，这意味着 TLS 之上的应用程序协议已加密，因此您看不到 URL。但是，您当然可以看到 TCP 标头和 TLS 标头。– 罗马2017 年 12 月 28 日 10:47
4 个答案
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 发出请求，攻击者会看到什么？让我们从网络上的被动窃听者的角度来看前面的假设请求。如果我想知道您正在访问什么，我只有有限的选择：
- 我看到您发出一个使用 TLS 加密的 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.htmlhttp://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（不包括片段），因此请记住这一点。
-
1
-
@jdoe 它唯一需要的地址是域本身的地址。它的其余部分可以托管在同一个系统上，知道如何连接
example.com/foo并且example.com/bar只需要知道如何连接到example.com它自己。– 森林2017 年 12 月 28 日 9:11 -
这里不是 100% 确定，但是当您从 HTTPS 转换到 HTTP 时，浏览器不应该不发送引用策略吗？我认为这可以通过明确设置不同的引用策略来改变（就像我认为谷歌所做的那样），但希望 URL 敏感的网站不会这样做。– 否则2017 年 12 月 28 日 10:04
-
@Anders 一些浏览器可能会这样做，但它不是任何规范的一部分，因此在重要情况下不应依赖它。理想情况下，URL 敏感的站点会设置适当的引用策略以在敏感页面上完全禁用它，但许多（如果不是大多数）不这样做。– 森林2017 年 12 月 28 日 10:06
-
天真的答案是否定的：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 片段触发不同的网络流量。）
769
到【灌水乐园】发言
