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

我同意前面的答案:

明确地说:

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

然而，您不应该在GET请求中放置参数的原因有很多。

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

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

虽然这里已经有了一些好的答案，但大多数都集中在浏览器导航方面。我在2018年写这篇文章，可能有人想知道移动应用程序的安全性。

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

这里唯一的“可能”是客户端或服务器感染了恶意软件，可以在数据被包装成https之前看到数据。但如果有人感染了这种软件，他们就可以访问数据，不管你用什么来传输数据。

Marc Novakowski的回答很有帮助——URL存储在服务器的日志中(例如，在/etc/httpd/logs/ssl_access_log中)，所以如果你不想让服务器长期保存这些信息，就不要把它放在URL中。

既然没人提供电汇，那就来一个。 服务器名(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”的扩展。

简而言之:

如果使用SNI扩展，FQDN (URL的域部分)可以在ClientHello包中清晰地传输 URL的其余部分(/path/?some=parameters&go=here)在ClientHello内部没有业务，因为请求URL是一个HTTP的东西(OSI第7层)，因此它永远不会在TLS握手中出现(第4层或第5层)。some=parameters&go=here HTTP/1.1 HTTP请求，安全TLS通道建立后。

执行概要

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

2019年3月更新

谢谢你，carlin。斯科特，谢谢你提起这件事。

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

CloudFlare正在做这件事，你可以在这里阅读更多关于内部的信息 如果先有鸡后有蛋，你会把鸡放在哪里?

实际上，这意味着FQDN不再以纯文本形式传输(如Wireshark捕获的内容所示)，而是被加密了。

注意:这解决了隐私方面的问题，而不是安全方面的问题，因为反向DNS查找可能会暴露预期的目标主机。

2020年9月更新

现在有一个RFC草案，用于加密整个客户端Hello消息，而不仅仅是SNI部分: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1

在撰写本文时，浏览器的支持非常有限。

It is now 2019 and the TLS v1.3 has been released. According to Cloudflare, the server name indication (SNI aka the hostname) can be encrypted thanks to TLS v1.3. So, I told myself great! Let's see how it looks within the TCP packets of cloudflare.com So, I caught a "client hello" handshake packet from a response of the cloudflare server using Google Chrome as browser & wireshark as packet sniffer. I still can read the hostname in plain text within the Client hello packet as you can see below. It is not encrypted.

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

所以，看起来SNI的加密需要额外的实现才能与TLSv1.3一起工作

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

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

在这一点上，我认为谷歌chrome不支持它。您可以在Firefox中手动激活加密SNI。当我因为某种原因尝试它时，它并没有立即起作用。我重启了两次Firefox，它才开始工作:

URL字段类型:about:config。

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

去我之前提到的那个网站。

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