我同意前面的答案:

明确地说:

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

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

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

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

正如其他答案已经指出的，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的日志文件中检索它。)

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

You can not always count on privacy of the full URL either. For instance, as is sometimes the case on enterprise networks, supplied devices like your company PC are configured with an extra "trusted" root certificate so that your browser can quietly trust a proxy (man-in-the-middle) inspection of https traffic. This means that the full URL is exposed for inspection. This is usually saved to a log. Furthermore, your passwords are also exposed and probably logged and this is another reason to use one time passwords or to change your passwords frequently. Finally, the request and response content is also exposed if not otherwise encrypted. One example of the inspection setup is described by Checkpoint here. An old style "internet café" using supplied PC's may also be set up this way.

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

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