HTTPS URL是否已加密？

Question

使用TLS/SSL(HTTPS)加密时是否加密了所有URL？我想知道,因为我希望在使用TLS/SSL(HTTPS)时隐藏所有URL数据.

如果TLS/SSL为您提供全面的URL加密,那么我不必担心从URL隐藏机密信息.

Answer 1

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

Answer 2

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

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

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

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

3.1.服务器名称指示

[TLS]没有为客户端提供一种机制来告诉服务器它正在联系的服务器的名称. 客户端可能希望提供此信息以促进与在单个底层网络地址处托管多个"虚拟"服务器的服务器的安全连接.

为了提供服务器名称,客户端可以在(扩展)客户端hello中包含"server_name"类型的扩展名.

简而言之:

• FQDN(URL的域部分)可能被发送以明文内部ClientHello分组如果使用SNI扩展

• URL(/path/?some=parameters&go=here)的其余部分没有业务,ClientHello因为请求URL是HTTP事物(OSI第7层),因此它永远不会出现在TLS握手(第4层或第5层)中.这会后来在一个GET /path/?some=parameters&go=here HTTP/1.1HTTP请求中,后的安全 TLS通道建立.

执行摘要

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

Answer 3

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

Answer 4

整个请求和响应都是加密的,包括URL.

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

Answer 5

我同意以前的答案:

要明确:

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

但是,为什么不应该在GET请求中放置参数有很多原因.

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

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

Answer 6

来自Marc Novakowski的有用答案的补充 - URL存储在服务器上的日志中(例如,在/ etc/httpd/logs/ssl_access_log中),因此如果您不希望服务器在更长时间内维护信息术语,不要把它放在URL中.

Answer 7

是的,不是.

服务器地址部分未加密,因为它用于设置连接.

这可能会在未来使用加密的SNI和DNS进行更改,但截至2018年,两种技术都不常用.

路径,查询字符串等是加密的.

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

Answer 8

现在是 2019 年，TLS v1.3 已经发布。根据 Cloudflare 的说法，服务器名称指示（SNI 又名主机名）可以通过 TLS v1.3 进行加密。所以，我告诉自己很棒！让我们看看它在 cloudflare.com 的 TCP 数据包中的外观因此，我从 cloudflare 服务器的响应中捕获了一个“client hello”握手数据包，使用 Google Chrome 作为浏览器，wireshark 作为数据包嗅探器。我仍然可以在客户端 hello 数据包中以纯文本形式读取主机名，如下所示。它没有加密。

因此，请注意您可以阅读的内容，因为这仍然不是匿名连接。客户端和服务器之间的中间件应用程序可以记录客户端请求的每个域。

因此，看起来 SNI 的加密需要额外的实现才能与 TLSv1.3 一起使用

2020 年 6 月更新：看起来加密 SNI 是由浏览器启动的。Cloudflare 有一个页面供您检查您的浏览器是否支持加密 SNI：

https://www.cloudflare.com/ssl/encrypted-sni/

在这一点上，我认为谷歌浏览器不支持它。您可以在 Firefox 中手动激活加密 SNI。当我出于某种原因尝试它时，它并没有立即起作用。我在 Firefox 工作之前重新启动了两次：

在 URL 字段中键入：about:config。

检查 network.security.esni.enabled 是否为真。清除缓存/重新启动

去网站，我之前提到过。

正如您所看到的，今天 VPN 服务对于想要确保咖啡店老板不会记录人们访问的网站列表的人来说仍然很有用。

Answer 9

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

一般来说,其他答案是正确的,但实际上这篇论文表明访问的页面(即URL)可以非常有效地确定.

Answer 10

虽然您已经有了很好的答案，但我真的很喜欢这个网站上的解释： https: //https.cio.gov/faq/#what-information-does-https-protect

简而言之：使用 HTTPS 隐藏：

• HTTP方式
• 查询参数
• POST 正文（如果存在）
• 请求标头（包括 cookie）
• 状态码

Answer 11

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

Answer 12

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

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

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

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

Answer 13

虽然这里已经有一些很好的答案，但其中大部分都集中在浏览器导航上。我是在 2018 年写这篇文章的，可能有人想了解移动应用程序的安全性。

对于移动应用程序，如果您控制应用程序的两端（服务器和应用程序），只要您使用 HTTPS，您就是安全的。iOS 或 Android 将验证证书并减轻可能的 MiM 攻击（这将是所有这些中唯一的弱点）。您可以通过 HTTPS 连接发送敏感数据，这些数据将在传输过程中加密。只有您的应用程序和服务器会知道通过 https 发送的任何参数。

这里唯一的“可能”是客户端或服务器是否感染了恶意软件，这些软件可以在将数据封装在 https 中之前查看数据。但是如果有人感染了这种软件，无论您使用什么来传输数据，他们都可以访问数据。