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

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

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

是也不是。

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

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

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

注意，对于GET请求，用户仍然可以从位置栏中剪切和粘贴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。

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

我同意前面的答案:

明确地说:

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

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

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

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