HTTPS URL 是否加密？
使用 TLS/SSL (HTTPS) 加密时是否对所有 URL 进行了加密？我想知道，因为我希望在使用 TLS/SSL (HTTPS) 时隐藏所有 URL 数据。
如果 TLS/SSL 为您提供完整的 URL 加密，那么我不必担心隐藏 URL 中的机密信息。
https://somewhere_i_trust/ways_to_protest_against_the_government/。然后 URL 包含机密数据，即我正在考虑抗议我的政府的建议。
是的，SSL 连接位于 TCP 层和 HTTP 层之间。客户端和服务器首先建立一个安全的加密 TCP 连接（通过 SSL/TLS 协议），然后客户端将通过该加密的 TCP 连接发送 HTTP 请求（GET、POST、DELETE...）。
Note however（也如评论中所述）URL 的 域名 部分在 TLS 协商的第一部分以明文形式发送。因此，可以嗅探服务器的域名。但不是 URL 的其余部分。
由于没有人提供线路捕获，因此这里提供了一个。
服务器名称（URL 的域部分）以纯文本 形式出现在 ClientHello 数据包中。
下面显示了一个浏览器请求：
https://i.stack.imgur.com/path/?some=parameters&go=here
https://i.stack.imgur.com/rdHZZ.png
从 https://www.ietf.org/rfc/rfc3546.txt：
3.1。服务器名称指示 [TLS] 没有为客户端提供一种机制来告诉服务器它正在联系的服务器的名称。客户端可能希望提供此信息以促进与在单个底层网络地址托管多个“虚拟”服务器的服务器的安全连接。
为了提供服务器名称，客户端可以在（扩展的）客户端 hello 中包含类型为“server_name”的扩展。
简而言之：
如果使用 SNI 扩展，FQDN（URL 的域部分）可以在 ClientHello 数据包中以明文形式传输
URL 的其余部分（/path/?some=parameters&go=here）在 ClientHello 内部没有任何业务，因为请求 URL 是 HTTP 事物（OSI 第 7 层），因此它永远不会出现在 TLS 握手（第 4 层或5）。这将在 GET /path/?some=parameters&go=here HTTP/1.1 HTTP 请求中稍后出现，在建立安全 TLS 通道之后。
执行摘要
域名可以明文传输（如果在 TLS 握手中使用 SNI 扩展），但 URL（路径和参数）始终是加密的。
2019 年 3 月更新
感谢carlin.scott提出这个问题。
现在可以通过 this draft RFC proposal 加密 SNI 扩展中的负载。此功能仅存在于 TLS 1.3 中（作为一个选项，由两端来实现）并且与 TLS 1.2 及更低版本没有向后兼容性。
CloudFlare 正在这样做，您可以在此处阅读有关内部结构的更多信息 — If the chicken must come before the egg, where do you put the chicken?
在实践中，这意味着现在不是以纯文本形式传输 FQDN（如 Wireshark 捕获节目），而是对其进行加密。
注意：这解决了隐私方面的问题，而不是安全方面的问题，因为反向 DNS 查找可能无论如何都会显示预期的目标主机。
2020 年 9 月更新
现在有一个用于加密整个 Client Hello 消息的 RFC 草案，而不仅仅是 SNI 部分：https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1
在撰写此浏览器时，支持非常有限。
正如 other answers 已经指出的那样，https“URL”确实是加密的。但是，您在解析域名时的 DNS 请求/响应可能不是，当然，如果您使用的是浏览器，您的 URL 也可能会被记录。
整个请求和响应都是加密的，包括 URL。
请注意，当您使用 HTTP 代理时，它知道目标服务器的地址（域），但不知道该服务器上的请求路径（即请求和响应总是加密的）。
我同意前面的回答：
明确地说：
使用 TLS，URL 的第一部分 (https://www.example.com/) 在建立连接时仍然可见。第二部分（/hereemygetparameters/1/2/3/4）受 TLS 保护。
但是，有很多原因导致您不应该在 GET 请求中放入参数。
首先，正如其他人已经提到的： - 通过浏览器地址栏泄漏 - 通过历史记录泄漏
除此之外，您还通过 http 引用者泄漏了 URL：用户在 TLS 上看到站点 A，然后单击指向站点 B 的链接。如果两个站点都在 TLS 上，则对站点 B 的请求将包含来自站点 A 的完整 URL请求的referer参数。站点 B 的管理员可以从服务器 B 的日志文件中检索它。）
是和不是。
服务器地址部分未加密，因为它用于建立连接。
这可能会在未来随着加密的 SNI 和 DNS 而改变，但截至 2018 年，这两种技术都不常用。
路径、查询字符串等被加密。
请注意，对于 GET 请求，用户仍然可以从地址栏中剪切和粘贴 URL，并且您可能不希望在其中放置任何人都可以看到屏幕的机密信息。
Marc Novakowski 提供的有用答案的补充 - URL 存储在服务器上的日志中（例如，在 /etc/httpd/logs/ssl_access_log 中），因此如果您不希望服务器长时间维护信息术语，不要放在 URL 中。
现在是 2019 年，TLS v1.3 已经发布。根据 Cloudflare，服务器名称指示（SNI 又名主机名）可以通过 TLS v1.3 进行加密。所以，我告诉自己很棒！让我们看看它在 cloudflare.com 的 TCP 数据包中的样子。因此，我从 cloudflare 服务器的响应中捕获了一个“client hello”握手数据包，使用 Google Chrome 作为浏览器，wireshark 作为数据包嗅探器。我仍然可以在客户端 hello 数据包中以纯文本格式读取主机名，如下所示。它没有加密。
https://i.stack.imgur.com/BZDy4.jpg
因此，请注意您可以阅读的内容，因为这仍然不是匿名连接。客户端和服务器之间的中间件应用程序可以记录客户端请求的每个域。
因此，看起来 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 服务今天对于想要确保咖啡店老板不记录人们访问的网站列表的人来说仍然有用。
network.security.esni.enabled，将 network.trr.mode 设置为 2（当前将您的 DoH 解析器设置为 CloudFlare），然后重新启动浏览器（原文如此！）；然后它将使用 ESNI - 由域的基础设施支持。有关详细信息，请参阅 blog.mozilla.org/security/2018/10/18/…。
监控流量的第三方也可以通过检查您的流量并将其与其他用户访问该站点时的流量进行比较来确定访问的页面。例如，如果一个站点上只有 2 个页面，其中一个比另一个大得多，那么比较数据传输的大小将知道您访问了哪个页面。有一些方法可以对第三方隐藏，但它们不是正常的服务器或浏览器行为。例如，参见 SciRate 的这篇论文，https://scirate.com/arxiv/1403.0297。
一般来说，其他答案是正确的，尽管本文表明可以非常有效地确定访问的页面（即 URL）。
您也不能总是指望完整 URL 的隐私。例如，在企业网络中有时会出现这种情况，提供的设备（例如您的公司 PC）配置有额外的“受信任”根证书，以便您的浏览器可以安静地信任对 https 流量的代理（中间人）检查.这意味着完整的 URL 被公开以供检查。这通常保存到日志中。
此外，您的密码也被公开并可能被记录，这是使用 one time passwords 或经常更改密码的另一个原因。
最后，如果没有加密，请求和响应内容也会暴露。
Checkpoint here 描述了检查设置的一个示例。使用提供的 PC 的老式“网吧”也可以这样设置。
链接到我在 duplicate question 上的答案。 URL 不仅在浏览器历史记录和服务器端日志中可用，而且还作为 HTTP Referer 标头发送，如果您使用第三方内容，则会将 URL 暴露给您无法控制的来源。
尽管这里已经有一些很好的答案，但其中大多数都集中在浏览器导航上。我在 2018 年写这篇文章，可能有人想了解移动应用程序的安全性。
对于移动应用程序，如果您控制应用程序的两端（服务器和应用程序），只要您使用 HTTPS，您就很安全。 iOS 或 Android 将验证证书并减轻可能的 MiM 攻击（这将是所有这一切的唯一弱点）。您可以通过 HTTPS 连接发送敏感数据，这些数据将在传输过程中被加密。只有您的应用程序和服务器会知道通过 https 发送的任何参数。
这里唯一的“可能”是客户端或服务器是否感染了恶意软件，这些恶意软件可以在将数据包装在 https 中之前查看数据。但是，如果有人感染了这种软件，无论您使用什么来传输数据，他们都可以访问数据。
虽然您已经有了很好的答案，但我真的很喜欢这个网站上的解释：https://https.cio.gov/faq/#what-information-does-https-protect
简而言之：使用 HTTPS 隐藏：
HTTP方法
查询参数
POST 正文（如果存在）
请求标头（包括 cookie）
状态码
此外，如果您正在构建一个 ReSTful API，浏览器泄漏和 http 引用问题大多会得到缓解，因为客户端可能不是浏览器并且您可能没有人点击链接。
如果是这种情况，我建议使用 oAuth2 登录来获取不记名令牌。在这种情况下，唯一的敏感数据将是初始凭据......无论如何这可能应该在发布请求中
关注公众号
不定期副业成功案例分享
