HTTPS URL 是否已加密?

使用 TLS / SSL(HTTPS)加密时是否对所有 URL 都进行了加密?我想知道,因为我希望在使用 TLS / SSL(HTTPS)时隐藏所有 URL 数据。

如果 TLS / SSL 为您提供了完整的 URL 加密,那么我不必担心隐藏 URL 中的机密信息。

答案

是的,SSL 连接在 TCP 层和 HTTP 层之间。客户端和服务器首先(通过 SSL / TLS 协议)建立安全的加密 TCP 连接,然后客户端将通过该加密的 TCP 连接发送 HTTP 请求(GET,POST,DELETE ...)。

由于没有人提供电汇,这是一个。
服务器名称 (URL 的域部分)在ClientHello数据包中以纯文本形式显示

下面显示了浏览器的请求:
https://i.stack.imgur.com/path/?some=parameters&go=here

客户您好SNI 有关 TLS 版本字段的更多信息, 请参见此答案 (其中有 3 个 - 不是版本,每个字段都包含版本号!)

来自https://www.ietf.org/rfc/rfc3546.txt

3.1。服务器名称指示

[TLS] 没有为客户端提供一种机制来告知服务器它正在联系的服务器的名称。客户可能希望提供此信息,以促进与服务器的安全连接,这些服务器在单个基础网络地址上托管着多个 “虚拟” 服务器。

为了提供服务器名称,客户端可以在(扩展的)客户端问候中包含类型为 “server_name” 的扩展。


简而言之:

  • 如果使用 SNI 扩展名,则 FQDN(URL 的域部分) 可以ClientHello包内以明文形式传输

  • URL 的其余部分( /path/?some=parameters&go=here/path/?some=parameters&go=here ClientHello无关,因为请求 URL 是 HTTP 事物(OSI 第 7 层),因此它将永远不会出现在 TLS 握手中(第 4 层或 5)。建立安全 TLS 通道 ,稍后将在GET /path/?some=parameters&go=here HTTP/1.1 HTTP 请求中进行处理。


执行摘要

域名可以明文传输(如果在 TLS 握手中使用了 SNI 扩展名),但是 URL(路径和参数)始终是加密的。


2019 年 3 月更新

谢谢carlin.scott提出了这一点。

现在,可以通过此 RFC 提议草案对 SNI 扩展中的有效负载进行加密。此功能仅在 TLS 1.3 中存在(作为一个选项,并且要由两端实现),并且与 TLS 1.2 及以下版本不存在向后兼容性。

CloudFlare 正在这样做,您可以在此处了解更多内部信息— 如果鸡肉必须在鸡蛋之前出现,那么您将鸡肉放在哪里?

实际上,这意味着现在不再加密以纯文本形式发送 FQDN(如 Wireshark 捕获所示)。

注意:由于反向 DNS 查找可能仍会显示预期的目标主机,因此它比安全性更能解决隐私方面的问题。

正如其他 答案已经指出的那样,https“URL” 确实是加密的。但是,解析域名时您的 DNS 请求 / 响应可能不是,当然,如果您使用的是浏览器,URL 可能也会被记录下来。

整个请求和响应都已加密,包括 URL。

请注意,当您使用 HTTP 代理时,它知道目标服务器的地址(域),但不知道该服务器上的请求路径(即,请求和响应始终被加密)。

我同意先前的答案:

明确地说:

使用 TLS,URL 的第一部分( https://www.example.com/ )在建立连接时仍然可见。第二部分(/ herearemygetparameters / 1/2/3/4)受 TLS 保护。

但是,有很多原因导致您不应该在 GET 请求中放置参数。

首先,正如其他人已经提到的那样:- 通过浏览器地址栏泄漏 - 通过历史记录泄漏

除此之外,您还会通过 http 引荐网址泄漏 URL:用户在 TLS 上看到站点 A,然后单击指向站点 B 的链接。如果两个站点都在 TLS 上,则对站点 B 的请求将包含站点 A 中的完整 URL。请求的参照参数。站点 B 的管理员可以从服务器 B 的日志文件中检索它。)

马克 · 诺瓦科夫斯基(Marc Novakowski)的有用答案的补充 - URL 存储在服务器上的日志中(例如,存储在 / etc / httpd / logs / ssl_access_log 中),因此,如果您不希望服务器将信息保存更长的时间,术语,请勿将其放在 URL 中。

是的,没有。

服务器地址部分未加密,因为它用于建立连接。

加密的 SNI 和 DNS 将来可能会改变这种情况,但是截至 2018 年,这两种技术已不再普遍使用。

路径,查询字符串等已加密。

对于 GET 请求,请注意,用户仍然可以将 URL 剪切并粘贴到位置栏中,并且您可能不希望在其中放置任何人都可以看到屏幕的机密信息。

监视流量的第三方也可以通过检查您的流量并将其与其他用户访问该站点的流量进行比较来确定访问的页面。例如,如果一个站点上只有 2 个页面,一个页面比另一个页面大得多,那么比较数据传输的大小就会知道您访问了哪个页面。有几种方法可以将其隐藏给第三方,但它们不是正常的服务器或浏览器行为。例如,请参阅 SciRate 上的这篇论文, 网址为 https://scirate.com/arxiv/1403.0297

通常,其他答案是正确的,尽管实际上本文显示可以很有效地确定访问的页面(即 URL)。

您也不能总是依靠完整 URL 的私密性。例如,在企业网络中,有时会为所提供的设备(如公司 PC)配置额外的 “受信任” 根证书,以便您的浏览器可以安静地信任对 HTTPS 流量的代理(中间人)检查。这意味着公开了完整的 URL 供检查。通常将其保存到日志中。

此外,您的密码也会被公开并可能被记录下来,这是使用一次性密码或经常更改密码的另一个原因。

最后,如果未进行其他加密,则请求和响应内容也将公开。

Checkpoint 此处介绍了一种检查设置的示例。也可以通过这种方式设置使用提供的 PC 的老式 “网吧”。

链接到我对重复问题的回答 。 URL 不仅在浏览器历史记录中可用,而且服务器端日志也作为 HTTP Referer 标头发送,如果您使用第三方内容,则会将 URL 暴露给控件之外的源。