我同意前面的答案:

明确地说:

使用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之前看到数据。但如果有人感染了这种软件，他们就可以访问数据，不管你用什么来传输数据。

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服务今天仍然很有用。

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

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

但是请注意(在评论中也提到了)，URL的域名部分在TLS协商的第一部分以明文形式发送。因此，可以嗅出服务器的域名。但不是URL的其余部分。

是也不是。

服务器地址部分不加密，因为它是用来建立连接的。

这种情况可能会随着加密的SNI和DNS而改变，但截至2018年，这两种技术都不常用。

路径、查询字符串等都是加密的。

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