HTTPS URL是否已加密？
https://stackoverflow.com/questions/499591
-
20-08-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
使用TLS / SSL（HTTPS）加密时，是否对所有URL都进行了加密？我想知道，因为我希望在使用TLS / SSL（HTTPS）时隐藏所有URL数据。
如果TLS / SSL为您提供了完整的URL加密，那么我不必担心隐藏URL中的机密信息。
解决方案
是的，SSL连接位于TCP层和HTTP层之间。客户端和服务器首先（通过SSL / TLS协议）建立安全的加密TCP连接，然后客户端将通过该加密的TCP连接发送HTTP请求（GET，POST，DELETE ...）。
其他提示
由于没有人提供电汇，所以这里是一个。
服务器名称（URL的域部分）以通用文本标签代码包的形式出现在纯文本中。
以下显示了浏览器对以下内容的请求：
遗传标记代码
来自 https://www.ietf.org/rfc/rfc3546.txt ：
3.1。服务器名称指示
[TLS]不提供客户端告知服务器的机制 它正在联系的服务器的名称。 客户提供此信息以促进安全 连接到托管多个“虚拟”服务器的服务器 单个基础网络地址。
为了提供服务器名称，客户端可以包含一个 （扩展的）客户端问候中类型为“ server_name”的扩展名。
简而言之：
如果使用了SNI扩展名，则
FQDN（URL的域部分） MAY 将以明文的方式在
ClientHello数据包内进行传输 >URL的其余部分（
https://i.stack.imgur.com/path/?some=parameters&go=here）不在ClientHello内部，因为请求URL是HTTP事物（OSI第7层），因此它将永远不会出现在TLS握手中（第4层或第5层） 。稍后将在/path/?some=parameters&go=hereHTTP请求中建立安全 TLS通道 AFTER 。
执行摘要
域名可以明文传输（如果在TLS握手中使用了SNI扩展名），但是URL（路径和参数）始终是加密的。
2019年3月更新
感谢您 carlin.scott 提出了这一建议。
现在可以通过此RFC提案草案。此功能仅在TLS 1.3中存在（作为一种选择，并且要由两端实现），并且与TLS 1.2及更低版本没有向后兼容性。
CloudFlare正在这样做，您可以在此处阅读有关内部的更多信息- 如果鸡肉必须在鸡蛋之前出现，那么您将鸡肉放在哪里？
实际上，这意味着它现在已经加密了，而不是以纯文本形式发送FQDN（如Wireshark捕获所示）。
注意：：由于反向DNS查找可能仍然会显示预期的目标主机，因此它比安全性更能解决隐私方面的问题。
整个请求和响应都已加密，包括URL。
请注意，当您使用HTTP代理时，它知道目标服务器的地址（域），但不知道该服务器上的请求路径（即请求和响应始终被加密）。
我同意之前的回答：
明确地说：
使用TLS，URL的第一部分（ https://www.example.com/ ）建立连接时仍然可见。第二部分（/ herearemygetparameters / 1/2/3/4）受TLS保护。
但是，有许多原因导致您不应该在GET请求中放置参数。
首先，正如其他人已经提到的那样： -通过浏览器地址栏泄漏 -通过历史泄漏
此外，您还会通过http引荐网址泄漏URL：用户看到TLS上的站点A，然后单击指向站点B的链接。如果两个站点都位于TLS上，则对站点B的请求将包含来自请求的引荐参数中的站点A。站点B的管理员可以从服务器B的日志文件中检索它。）
除了Marc Novakowski有用的答案外，URL还存储在服务器上的日志中（例如，存储在/ etc / httpd / logs / ssl_access_log中），因此，如果您不希望服务器维护信息，从长远来看，请勿将其放在URL中。
是，不是。
服务器地址部分未加密，因为它用于建立连接。
将来使用加密的SNI和DNS可能会改变这种情况，但是截至2018年，这两种技术已不再普遍使用。
路径，查询字符串等均已加密。
关于GET请求的注释，用户仍然可以将URL剪切并粘贴到位置栏中，并且您可能不希望在其中放置任何人都可以看到的机密信息。
监视流量的第三方也可以通过检查您的流量并将其与其他用户访问该站点的流量进行比较来确定访问的页面。例如，如果一个站点上只有2个页面，一个页面比另一个页面大得多，那么比较数据传输的大小就会知道您访问了哪个页面。有几种方法可以将其隐藏给第三方，但它们不是正常的服务器或浏览器行为。例如，请参见SciRate的这篇论文， https://scirate.com/arxiv/1403.0297 。
一般而言，其他答案也是正确的，尽管实际上本文显示可以相当有效地确定访问的页面（即URL）。
链接到我对重复问题的答案。该URL不仅在浏览器历史记录中可用，而且服务器端日志也以HTTP Referer标头发送，如果您使用第三方内容，则将该URL暴露给您控制之外的源。
您也不能总是指望完整URL的私密性。例如，有时在企业网络中，像公司PC这样的提供的设备都配置了额外的“受信任”根证书，以便您的浏览器可以安静地信任对HTTPS流量的代理（中间人）检查。这意味着公开了完整的URL供检查。通常将其保存到日志中。
此外，您的密码也已公开并且可能已记录，这是使用一次性密码，或者经常更改您的密码。
最后，如果未进行其他加密，则请求和响应内容也将公开。
此处的检查点描述了一种检查设置的示例。也可以通过这种方式设置使用提供的PC的老式“ Internetcafé”。
现在是2019年，并且TLS v1.3已发布。根据Cloudflare的说法，借助TLS v1.3，可以对SNI进行加密。所以，我告诉自己太好了！让我们看看它在cloudflare.com的TCP数据包中如何显示 因此，我从cloudflare服务器的响应中捕获了一个“ client hello”握手数据包，该数据包使用Google Chrome作为浏览器，wireshark作为数据包嗅探器。我仍然可以在Client hello数据包中以纯文本格式读取服务器名称。
因此，请注意您可以阅读的内容，因为它仍然不是匿名连接，因为中介可以看到目标服务器名称。
因此，看起来SNI的加密需要其他实现才能与TLSv1.3一起使用
以下文章介绍了Cloudflare作为TLSv1.3的一部分提供的SNI的加密。但是，在TLS v1.3之下，cloudflare.com上的所有HTTP URL均为TCP数据包中的纯文本
尽管这里已经有一些不错的答案，但大多数答案都集中在浏览器导航上。我在2018年写这篇文章，可能有人想知道移动应用程序的安全性。
对于移动应用程序，如果您控制应用程序的两端（服务器和应用程序），则只要使用HTTPS 就可以安全。iOS或Android将验证证书并缓解可能的MiM攻击（这将是所有这方面的唯一弱点）。您可以通过HTTPS连接发送敏感数据，该数据将在传输过程中进行加密。仅您的应用程序和服务器将知道通过https发送的所有参数。
这里唯一的“可能”是，如果客户端或服务器感染了恶意软件，这些恶意软件可以在将数据包装到https中之前先查看数据。但是，如果有人感染了这种软件，无论您使用什么方式进行传输，他们都将有权访问数据。
此外，如果您要构建ReSTful API，则可以最大程度地缓解浏览器泄漏和http引用问题，因为客户端可能不是浏览器，并且可能没有人点击链接。
如果是这种情况，我建议使用oAuth2登录以获取承载令牌。在这种情况下，唯一敏感的数据将是初始凭证...无论如何应该应该在发布请求中
