【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 
使用TLS / SSL（HTTPS）加密时是否加密了所有URL？ 我想知道，因为我希望在使用TLS / SSL（HTTPS）时隐藏所有URL数据。
如果TLS / SSL为您提供全面的URL加密，那么我不必担心从URL隐藏机密信息。
#1楼
我同意以前的答案：
要明确：
使用TLS，URL的第一部分（ https://www.example.com/ ）在构建连接时仍然可见。 第二部分（/ herearemygetparameters / 1/2/3/4）受TLS保护。
但是，为什么不应该在GET请求中放置参数有很多原因。
首先，正如其他人已经提到的那样： - 通过浏览器地址栏泄漏 - 历史泄漏
除此之外，您通过http referer泄露URL：用户在TLS上看到站点A，然后单击指向站点B的链接。如果两个站点都在TLS上，则对站点B的请求将包含站点A中的完整URL。请求的referer参数。 站点B的管理员可以从服务器B的日志文件中检索它。）
#2楼
正在监控流量的第三方也可以通过检查您的流量来确定所访问的页面，并将其与访问该站点时其他用户拥有的流量进行比较。 例如，如果一个站点上只有2个页面，一个比另一个大得多，那么比较数据传输的大小就会告诉你访问了哪个页面。 有些方法可以从第三方隐藏，但它们不是正常的服务器或浏览器行为。 例如，参见SciRate的这篇论文， https： //scirate.com/arxiv/1403.0297。
一般来说，其他答案是正确的，但实际上这篇论文表明访问的页面（即URL）可以非常有效地确定。
#3楼
在重复的问题上链接到我的答案。 不仅URL在浏览器历史记录中可用，服务器端日志，而且它也作为HTTP Referer标头发送，如果您使用第三方内容，则将URL公开给您控制之外的源。
#4楼
由于没有人提供线捕获，这里是一个。
服务器名称 （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查找可能无论如何都会显示预期的目标主机。
#5楼
您也不能始终依赖完整URL的隐私。 例如，正如企业网络上的情况一样，像公司PC这样的提供的设备配置了额外的“可信”根证书，这样您的浏览器就可以安静地信任https流量的代理（中间人）检查。 这意味着公开了完整的URL以供检查。 这通常保存到日志中。
此外，您的密码也会暴露并可能已记录，这是使用一次性密码或经常更改密码的另一个原因。
最后，如果没有加密，请求和响应内容也会暴露。
Checkpoint在此描述了检查设置的一个示例。 使用提供的PC的旧式“网吧”也可以这种方式设置。
来源：oschina
链接：https://my.oschina.net/u/3797416/blog/3143262