HTTPS URL 是否已加密？
使用 TLS / SSL（HTTPS）加密时是否加密了所有 URL？我想知道，因为我希望在使用 TLS / SSL（HTTPS）时隐藏所有 URL 数据。
如果 TLS / SSL 为您提供全面的 URL 加密，那么我不必担心从 URL 隐藏机密信息。
答案
是的，SSL 连接位于 TCP 层和 HTTP 层之间。客户端和服务器首先建立安全的加密 TCP 连接（通过 SSL / TLS 协议），然后客户端将通过该加密的 TCP 连接发送 HTTP 请求（GET，POST，DELETE ...）。
由于没有人提供线捕获，这里是一个。
服务器名称 （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 扩展，则可以在
ClientHello数据包内明确传输 FQDN（URL 的域部分）URL 的其余部分（
/path/?some=parameters&go=here）在ClientHello没有业务，因为请求 URL 是 HTTP 事物（OSI 第 7 层），因此它永远不会出现在 TLS 握手中（第 4 层或 5）。这会后来在一个GET /path/?some=parameters&go=here HTTP/1.1HTTP 请求之后 ，TLS 安全通道建立。
执行摘要
域名可以明确传输（如果在 TLS 握手中使用 SNI 扩展），但 URL（路径和参数）始终是加密的。
2019 年 3 月更新
谢谢carlin.scott带来这个。
SNI 扩展中的有效负载现在可以通过RFC 草案提案进行加密。此功能仅存在于 TLS 1.3 中（作为选项，它可以实现两端）并且与 TLS 1.2 及更低版本没有向后兼容性。
CloudFlare 正在这样做，你可以在这里阅读更多关于内部的内容 - 如果鸡必须在鸡蛋前面，你在哪里放鸡肉？
实际上，这意味着它不是以纯文本形式传输 FQDN（如 Wireshark 捕获节目），而是加密。
注意：由于反向 DNS 查找可能无论如何都会显示预期的目标主机，因此这比安全性更能解决隐私问题。