使用TLS / SSL（HTTPS）加密时是否加密所有URL？我想知道，因为我希望在使用TLS / SSL（HTTPS）时隐藏所有URL数据 .
如果TLS / SSL为您提供全面的URL加密，那么我不必担心从URL隐藏机密信息 .
整个请求和响应都是加密的，包括URL .
请注意，当您使用HTTP代理时，它知道目标服务器的地址（域），但不知道此服务器上的请求路径（即请求和响应始终是加密的） .
正在监控流量的第三方也可以通过检查您的流量来确定所访问的页面，并将其与访问该站点时其他用户拥有的流量进行比较 . 例如，如果一个站点上只有2个页面，一个比另一个大得多，那么数据传输大小的比较将告诉您访问了哪个页面 . 有些方法可以从第三方隐藏，但它们不是正常的服务器或浏览器行为 . 例如，参见SciRate的这篇论文，https://scirate.com/arxiv/1403.0297 .
一般来说，其他答案是正确的，实际上虽然本文表明访问的页面（即URL）可以非常有效地确定 .
是的，不是 .
这可能会在未来使用加密的SNI和DNS进行更改，但截至2018年，这两种技术都不常用 .
请注意，对于GET请求，用户仍然可以将URL剪切并粘贴到位置栏之外，您可能不希望将机密信息放在那里，任何看到屏幕的人都可以看到 .
链接到duplicate question上的答案 . 不仅URL在浏览器历史记录中可用，服务器端日志，而且它也作为HTTP Referer标头发送，如果您使用第三方内容，则将URL公开给您控制之外的源 .
正如other answers已经指出的那样，https "URLs"确实是加密的 . 但是，您在解析域名时的DNS请求/响应可能不是，当然，如果您使用的是浏览器，您的URL也可能被记录下来 .
由于没有人提供线捕获，这里是一个 .Server Name （URL的域部分）显示在 ClientHello 数据包中，位于 plain text 中 .
ClientHello
以下显示了一个浏览器请求：https://i.stack.imgur.com/path/?some=parameters&go=here
https://i.stack.imgur.com/path/?some=parameters&go=here
See this answer了解有关TLS版本字段的更多信息（其中有3个 - 不是版本，每个字段都包含版本号！）
来自https://www.ietf.org/rfc/rfc3546.txt：
3.1 . 服务器名称指示[TLS]不提供客户端告知服务器其正在联系的服务器的名称的机制 . 客户端可能希望提供此信息以促进与在单个底层网络地址处托管多个“虚拟”服务器的服务器的安全连接 . 为了提供服务器名称，客户端可以在（扩展）客户端hello中包含“server_name”类型的扩展名 .
FQDN（URL的域部分） MAY 如果使用SNI扩展，则在 ClientHello 数据包内传输 in clear
URL的其余部分（ /path/?some=parameters&go=here ）没有业务在 ClientHello 内，因为请求URL是HTTP事物（OSI第7层），因此它永远不会出现在TLS握手（第4层或第5层）中 . 稍后将在 GET /path/?some=parameters&go=here HTTP/1.1 HTTP请求中， AFTER Build secure TLS通道 .
/path/?some=parameters&go=here
GET /path/?some=parameters&go=here HTTP/1.1
域名可以明确传输（如果在TLS握手中使用SNI扩展），但URL（路径和参数）始终是加密的 .
您也不能始终依赖完整URL的隐私 . 例如，正如企业网络上的情况一样，像公司PC这样的提供设备配置了额外的“可信”根证书，这样您的浏览器就可以安静地信任https流量的代理（中间人）检查 . 这意味着将公开完整的URL以供检查 . 这通常保存到日志中 .
此外，您的密码也会暴露并可能已记录，这是使用one time passwords或经常更改密码的另一个原因 .
最后，如果没有加密，请求和响应内容也会暴露 .
Checkpoint here描述了检查设置的一个示例 . 使用提供的PC的旧样式"internet café"也可以通过这种方式设置 .
虽然这里有一些好的答案，但大多数都专注于浏览器导航 . 我在2018年写这篇文章，可能有人想知道移动应用程序的安全性 .
For mobile apps ，如果你控制应用程序的两端（服务器和应用程序），只要你使用HTTPS you're secure . iOS或Android将验证证书并减轻可能的MiM攻击（这将是所有这些中唯一的弱点） . 您可以通过HTTPS连接发送敏感数据加密 during transport . 只需您的应用和服务器就能知道通过https发送的任何参数 .
这里唯一的“可能”是，如果客户端或服务器感染了恶意软件，可以在将数据包装成https之前查看数据 . 但是，如果有人感染了这种软件，他们就可以访问数据，无论您使用什么来传输数据 .
此外，如果您正在构建ReSTful API，浏览器泄漏和http referer问题大多会减轻，因为客户端可能不是浏览器，您可能没有人点击链接 .
如果是这种情况，我建议oAuth2登录以获取持票令牌 . 在这种情况下，唯一的敏感数据将是初始凭证......无论如何，这应该在邮寄请求中
来自Marc Novakowski的有用答案的补充 - URL存储在服务器上的日志中（例如，在/ etc / httpd / logs / ssl_access_log中），因此如果您不希望服务器在更长时间内维护信息术语，不要把它放在URL中 .
是的，SSL连接位于TCP层和HTTP层之间 . 客户端和服务器首先 Build 安全的加密TCP连接（通过SSL / TLS协议），然后客户端将通过该加密的TCP连接发送HTTP请求（GET，POST，DELETE ...） .
我同意以前的答案：
要明确：
使用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的日志文件中检索它 . ）
12 回答
整个请求和响应都是加密的，包括URL .
请注意，当您使用HTTP代理时，它知道目标服务器的地址（域），但不知道此服务器上的请求路径（即请求和响应始终是加密的） .
正在监控流量的第三方也可以通过检查您的流量来确定所访问的页面，并将其与访问该站点时其他用户拥有的流量进行比较 . 例如，如果一个站点上只有2个页面，一个比另一个大得多，那么数据传输大小的比较将告诉您访问了哪个页面 . 有些方法可以从第三方隐藏，但它们不是正常的服务器或浏览器行为 . 例如，参见SciRate的这篇论文，https://scirate.com/arxiv/1403.0297 .
一般来说，其他答案是正确的，实际上虽然本文表明访问的页面（即URL）可以非常有效地确定 .
是的，不是 .
服务器地址部分未加密，因为它用于设置连接 .
这可能会在未来使用加密的SNI和DNS进行更改，但截至2018年，这两种技术都不常用 .
路径，查询字符串等已加密 .
请注意，对于GET请求，用户仍然可以将URL剪切并粘贴到位置栏之外，您可能不希望将机密信息放在那里，任何看到屏幕的人都可以看到 .
链接到duplicate question上的答案 . 不仅URL在浏览器历史记录中可用，服务器端日志，而且它也作为HTTP Referer标头发送，如果您使用第三方内容，则将URL公开给您控制之外的源 .
正如other answers已经指出的那样，https "URLs"确实是加密的 . 但是，您在解析域名时的DNS请求/响应可能不是，当然，如果您使用的是浏览器，您的URL也可能被记录下来 .
由于没有人提供线捕获，这里是一个 .
Server Name （URL的域部分）显示在
ClientHello数据包中，位于 plain text 中 .以下显示了一个浏览器请求：
https://i.stack.imgur.com/path/?some=parameters&go=hereSee this answer了解有关TLS版本字段的更多信息（其中有3个 - 不是版本，每个字段都包含版本号！）
来自https://www.ietf.org/rfc/rfc3546.txt：
简而言之：
FQDN（URL的域部分） MAY 如果使用SNI扩展，则在
ClientHello数据包内传输 in clearURL的其余部分（
/path/?some=parameters&go=here）没有业务在ClientHello内，因为请求URL是HTTP事物（OSI第7层），因此它永远不会出现在TLS握手（第4层或第5层）中 . 稍后将在GET /path/?some=parameters&go=here HTTP/1.1HTTP请求中， AFTER Build secure TLS通道 .执行摘要
域名可以明确传输（如果在TLS握手中使用SNI扩展），但URL（路径和参数）始终是加密的 .
您也不能始终依赖完整URL的隐私 . 例如，正如企业网络上的情况一样，像公司PC这样的提供设备配置了额外的“可信”根证书，这样您的浏览器就可以安静地信任https流量的代理（中间人）检查 . 这意味着将公开完整的URL以供检查 . 这通常保存到日志中 .
此外，您的密码也会暴露并可能已记录，这是使用one time passwords或经常更改密码的另一个原因 .
最后，如果没有加密，请求和响应内容也会暴露 .
Checkpoint here描述了检查设置的一个示例 . 使用提供的PC的旧样式"internet café"也可以通过这种方式设置 .
虽然这里有一些好的答案，但大多数都专注于浏览器导航 . 我在2018年写这篇文章，可能有人想知道移动应用程序的安全性 .
For mobile apps ，如果你控制应用程序的两端（服务器和应用程序），只要你使用HTTPS you're secure . iOS或Android将验证证书并减轻可能的MiM攻击（这将是所有这些中唯一的弱点） . 您可以通过HTTPS连接发送敏感数据加密 during transport . 只需您的应用和服务器就能知道通过https发送的任何参数 .
这里唯一的“可能”是，如果客户端或服务器感染了恶意软件，可以在将数据包装成https之前查看数据 . 但是，如果有人感染了这种软件，他们就可以访问数据，无论您使用什么来传输数据 .
此外，如果您正在构建ReSTful API，浏览器泄漏和http referer问题大多会减轻，因为客户端可能不是浏览器，您可能没有人点击链接 .
如果是这种情况，我建议oAuth2登录以获取持票令牌 . 在这种情况下，唯一的敏感数据将是初始凭证......无论如何，这应该在邮寄请求中
来自Marc Novakowski的有用答案的补充 - URL存储在服务器上的日志中（例如，在/ etc / httpd / logs / ssl_access_log中），因此如果您不希望服务器在更长时间内维护信息术语，不要把它放在URL中 .
是的，SSL连接位于TCP层和HTTP层之间 . 客户端和服务器首先 Build 安全的加密TCP连接（通过SSL / TLS协议），然后客户端将通过该加密的TCP连接发送HTTP请求（GET，POST，DELETE ...） .
我同意以前的答案：
要明确：
使用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的日志文件中检索它 . ）