使用TLS / SSL(HTTPS)加密时是否加密了所有URL？ 我想知道，因为我希望在使用TLS / SSL(HTTPS)时隐藏所有URL数据。
如果TLS / SSL为您提供全面的URL加密，那么我不必担心从URL隐藏机密信息。
-
无论如何，将机密数据放入URL可能是一个坏主意。它会在浏览器的地址显示不好，还记得吗？如果任何碰巧看一眼屏幕的人都能看到他们的密码，人们就不喜欢它了。为什么您认为需要将机密数据放入URL？
-
URL也存储在浏览器历史记录和服务器日志中 - 如果我想将我的名字和密码存储在某个地方，则不会出现在这两个地方。
-
例如，假设我访问https://somewhere_i_trust/ways_to_protest_against_the_government/。然后该URL包含机密数据，即我正在考虑抗议我的政府的建议。
-
当我从本机(而不是基于浏览器)的应用程序发出HTTP请求时，我问自己这个问题。我猜这可能会引起移动应用开发者的兴趣。在这种情况下，上面的评论(虽然是真的)是无关紧要的(没有网址可见，没有浏览历史记录)，作出答案，我的理解很简单："是的，它是加密的"。
-
@DannyA我也在考虑移动应用程序的情况时遇到了这个问题，该移动应用程序在查询字符串中向https：//地址发出了带有潜在机密信息的GET请求。
-
@DannyA在这里相同，但是用于构建REST Api。
-
对于那些认为一旦你是HTTPS的人，没有人知道你要去哪里，请先阅读：服务器的主机名(例如example.com)仍会因SNI而泄露。这与DNS完全无关，即使您不使用DNS或使用加密DNS也会发生泄漏。
-
伟大的文章，帮助!!我只有一件事要补充并寻求答案。一旦建立了TLS会话，IS就是暴露给中间人的实际协议方案。例如，如果我的应用程序级协议是https或ftps，则该方案即http或ftp可用于中间主。正如有人在这个链中提到的......"使用TLS，URL(example.com)的第一部分在构建连接时仍然可见。第二部分(/ herearemygetparameters / 1/2/3/4)受到保护通过TLS"我想对该计划进行更多澄清。谢谢。
-
可能重复加密HTTPS标头吗？
-
@jalf但是OAuth2中的auth代码是在URL中发送的，因为HTTP不支持跨带有标头或cookie的域的重定向。 oauth.com/oauth2-servers/access-tokens/…
是的，SSL连接位于TCP层和HTTP层之间。客户端和服务器首先建立安全的加密TCP连接(通过SSL / TLS协议)，然后客户端将通过该加密的TCP连接发送HTTP请求(GET，POST，DELETE ...)。
-
值得注意的是@Jalf在对问题本身的评论中提到的事情。 URL数据也将保存在浏览器的历史记录中，这可能是长期不安全的。
-
不只是GET或POST。也可以是DELETE，PUT，HEAD或TRACE。
-
或者你可以说它支持任何HTTP请求......
-
我想补充一下，记住亚马逊如何做到这一点。他们使用公共密钥和密钥对以及请求的到期日期。您必须使用Sha1和您的私钥来签署您的JSON请求。然后，您可以通过该线路发送公钥。亚马逊然后使用您的公钥在内部查找您的密钥，然后签署JSON。它必须匹配或请求被拒绝。这允许您将URL作为临时请求发送。在滚动自己的方法时要考虑模仿的东西。
-
是的，它可能是浏览器历史记录的安全问题。但在我的情况下，我不使用浏览器(原来的帖子也没有提到浏览器)。在本机应用程序中使用幕后自定义https调用。这是确保应用程序的服务器连接安全的简单解决方案。
-
但请注意，URL的DNS解析可能未加密。因此，有人嗅探您的流量可能仍然可能会看到您尝试访问的域。
-
@Jason Sebring认为这是一种奇怪的方式。为什么他们不使用自己的私钥来签署JSON？
-
@bukko它可能很奇怪，但它是一个标准，我在适合API消费的场景中全面看到。
-
@bukko：我认为Jason正在谈论这类事情：docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html，尽管在该特定协议中没有关于JSON的内容。如果是这样，那么当亚马逊"使用您的密钥签署JSON [请求]"时，他们就会确认HMAC。它不是公钥/私钥对，它是Amazon的共享密钥和非秘密用户标识符。
-
SNI打破了URL加密的"主机"部分。你可以用wireshark自己测试一下。有一个SNI选择器，或者您可以在连接到远程主机时查看SSL数据包。
-
@ChewToy DNS over HTTPS(DoH)修复了这个问题。但是仍然可以通过IP域找出用户连接到哪个域甚至与DoH匹配。
由于没有人提供线捕获，这里是一个。
服务器名称(URL的域部分)以纯文本形式显示在ClientHello数据包中。
以下显示了一个浏览器请求：
https://i.stack.imgur.com/path/?some=parameters&go=here
有关TLS版本字段的更多信息，请参阅此答案(其中有3个 - 不是版本，每个字段都包含版本号！)
来自https://www.ietf.org/rfc/rfc3546.txt：
3.1. Server Name Indication
[TLS] does not provide a mechanism for a client to tell a server
the name of the server it is contacting. It may be desirable for
clients to provide this information to facilitate secure
connections to servers that host multiple 'virtual' servers at a
single underlying network address.
In order to provide the server name, clients MAY include an
extension of type"server_name" in the (extended) client hello.
简而言之：
-
如果使用SNI扩展，则可以在ClientHello数据包内清除FQDN(URL的域部分)
-
URL的其余部分(/path/?some=parameters&go=here)没有业务在ClientHello内，因为请求URL是HTTP事物(OSI第7层)，因此它永远不会出现在TLS握手(第4层或第5层)中。在安全TLS通道建立之后，这将在稍后的GET /path/?some=parameters&go=here HTTP/1.1 HTTP请求中出现。
执行摘要
域名可以明确传输(如果在TLS握手中使用SNI扩展)，但URL(路径和参数)始终是加密的。
2019年3月更新
谢谢carlin.scott带来这个。
SNI扩展中的有效负载现在可以通过RFC草案提案进行加密。此功能仅存在于TLS 1.3中(作为选项，它可以实现两端)并且与TLS 1.2及更低版本没有向后兼容性。
CloudFlare正在这样做，你可以在这里阅读更多关于内部的信息＆mdash;
如果鸡必须来到鸡蛋前，你把鸡放在哪里？
实际上，这意味着它不是以纯文本形式传输FQDN(如Wireshark捕获节目)，而是加密。
注意：这比隐私方面更能解决隐私问题，因为反向DNS查找可能无论如何都会显示预期的目标主机。
-
完美的答案，从A到Z的完整解释。我喜欢执行摘要。让我的一天成为@evilSnobu
-
完美的答案，upvote！仍然考虑客户端部分，因为浏览器历史可能是泄漏。但是，关于传输层，URL参数是加密的。
-
你可能想要更新这个答案，因为TLS 1.3加密SNI扩展，而最大的CDN正在这样做：blog.cloudflare.com/encrypted-sni当然，数据包嗅探器可以只进行反向dns查找您要连接的IP地址。
正如其他答案已经指出的那样，https"URL"确实是加密的。但是，您在解析域名时的DNS请求/响应可能不是，当然，如果您使用的是浏览器，您的URL也可能被记录下来。
-
并且URL记录很重要，因为有Javascript黑客允许完全不相关的网站测试给定的URL是否在您的历史记录中。您可以通过在其中包含一个长的随机字符串来使URL不可用，但如果它是一个公共URL，那么攻击者可以告诉它已经被访问过，如果它有一个短信，那么攻击者就可以蛮力以合理的速度。
-
是不是也有加密的DNS？
-
@SteveJessop，请提供"Javascript hacks的链接，允许完全不相关的网站测试给定的URL是否在您的历史记录中"
-
@Pacerier：当然是黑客攻击日期，但当时我所谈论的是像stackoverflow.com/questions/2394890/…这样的东西。在2010年这是一个很大的问题，这些问题正在被调查，攻击得到了改进，但我现在并没有真正关注它。
-
@Pacerier：更多例子：webdevwonders.com/&hellip ;, webdevwonders.com/…
-
您可以将OpenDNS与其加密的DNS服务一起使用。我在Mac上使用它，但我发现Windows版本无法正常工作。那是不久前的事情，所以它现在可以正常工作了。对于Linux还没有。 opendns.com/about/innovations/dnscrypt
-
如果客户端是移动设备中的应用，那么您的说法是"如果您使用的是浏览器，您的网址也可能会被录制"仍然如此？我的意思是，网址可能会记录在某个地方？问候
整个请求和响应都是加密的，包括URL。
请注意，当您使用HTTP代理时，它知道目标服务器的地址(域)，但不知道此服务器上的请求路径(即请求和响应始终是加密的)。
-
整个请求。主机名以明文形式发送。其他所有都是加密的。
我同意以前的答案：
要明确：
使用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的日志文件中检索它。)
-
@EJP你不明白Tobias在说什么。他说如果你点击网站A上的链接将你带到网站B，那么网站B将获得引荐来源网址。例如，如果您在siteA.com?u=username&pw=123123上，则siteB.com(链接到siteA.com页面)将收到"siteA.com?u=username&pw=123123""作为引用URL，由浏览器发送到HTTPS内的siteB.com。如果这是真的，那就非常糟糕。这是真正的托比亚斯吗？
-
@EJP，由于所有现代网络浏览器都使用的SNI，域名是可见的。另请参阅EFF的这张图表，显示任何人都可以看到您正在访问的网站的域名。这与浏览器可见性无关。这是关于窃听者可见的内容。
-
@trusktr：浏览器不应该从HTTPS页面发送Referer标头。这是HTTP规范的一部分。
-
@MartinGeisler，关键字是"应该"。浏览器并不太关心"应该"(而不是"必须")。从您自己的链接："强烈建议用户能够选择是否发送Referer字段。例如，浏览器客户端可以有一个切换开关用于公开/匿名浏览，这将分别启用/禁用发送Referer和From information"。 Ops，这正是Chrome所做的。即使您处于隐身模式，Chrome也会泄漏推荐人。
来自Marc Novakowski的有用答案的补充 - URL存储在服务器上的日志中(例如，在/ etc / httpd / logs / ssl_access_log中)，因此如果您不希望服务器在更长时间内维护信息术语，不要把它放在URL中。
是的，不是。
服务器地址部分未加密，因为它用于设置连接。
这可能会在未来使用加密的SNI和DNS进行更改，但截至2018年，两种技术都不常用。
路径，查询字符串等是加密的。
请注意，对于GET请求，用户仍然可以将URL剪切并粘贴到位置栏之外，您可能不希望将机密信息放在那里，任何看到屏幕的人都可以看到。
-
想要+1这个，但我发现"是和否"误导 - 你应该改变它，只是指出服务器名称将使用DNS解析而不加密。
-
等等，作者在不正确的意义上使用URL这个词在哪里？
-
根据我的理解，OP在正确的意义上使用URL这个词。我认为这个答案更具误导性，因为它没有明确区分URL中的主机名和DNS解析中的主机名。
-
差异是......？
-
URL已加密。 HTTP事务的每个方面都是加密的。不仅仅是"其他一切"。期。 -1。
-
@EJP除了主机的DNS查找。哪个不是。期。
-
这不是HTTPS交易的一部分，与您在此处继续给出的误导性印象相反。
-
@EJP但DNS查找确实使用了URL的一个部分，因此对于非技术人员来说，整个URL都没有加密。仅仅使用Google.com查找非技术性内容的非技术人员不知道数据最终位于何处或如何处理。该域是用户访问的URL的一部分，并非100％加密，因为我作为攻击者可以嗅探他正在访问的站点。只有URL的/ path固有地加密给外行(这无关紧要)。
-
@EJP，@？trusktr，@？Lawrence，@？Guillaume。你们所有人都错了。这与DNS无关。 SNI"作为TLS协商的一部分发送虚拟域的名称"，因此即使您不使用DNS或DNS加密，嗅探器仍然可以看到您的请求的主机名。
-
所以在GET请求中参数是加密的但不是hostname + url upto params，但是在用户浏览器历史记录或代理服务器日志中它将包含完整的未编译的URL
正在监控流量的第三方也可以通过检查您的流量来确定所访问的页面，并将其与访问该站点时其他用户拥有的流量进行比较。例如，如果一个站点上只有2个页面，一个比另一个大得多，那么比较数据传输的大小就会告诉你访问了哪个页面。有些方法可以从第三方隐藏，但它们不是正常的服务器或浏览器行为。例如，参见SciRate的这篇论文，https：//scirate.com/arxiv/1403.0297。
一般来说，其他答案是正确的，但实际上这篇论文表明访问的页面(即URL)可以非常有效地
-
这实际上只适用于非常小的网站，在这些情况下，网站的主题/基调/性质在每一页上可能仍然大致相同。
-
根据我的引用："我们针对超过6000个网页提供流量分析攻击，这些网页涵盖了医疗保健，金融，法律服务和流媒体视频等10个广泛使用的行业领先网站的HTTPS部署。我们的攻击识别了同一个网站，准确度为89％[...]。看来你的可行性结论是错误的。
-
对于有兴趣阅读更多有关此类漏洞的人来说，这些类型的攻击通常被称为旁道攻击。
您也不能始终依赖完整URL的隐私。例如，正如企业网络上的情况一样，像公司PC这样的提供的设备配置了额外的"可信"根证书，这样您的浏览器就可以安静地信任https流量的代理(中间人)检查。这意味着公开了完整的URL以供检查。这通常保存到日志中。
此外，您的密码也会暴露并可能已记录，这是使用一次性密码或经常更改密码的另一个原因。
最后，如果没有加密，请求和响应内容也会暴露。
Checkpoint在此描述了检查设置的一个示例。使用提供的PC的旧式"网吧"也可以这种方式设置。
在重复的问题上链接到我的答案。不仅URL在浏览器历史记录中可用，服务器端日志，而且它也作为HTTP Referer标头发送，如果您使用第三方内容，则将URL公开给您控制之外的源。
-
提供您的第三方电话是HTTPS，虽然这不是问题吗？
-
它将使用第三方证书加密，以便他们可以看到URL
现在是2019年，TLS v1.3已经发布。 根据cloudflare，由于TLS v1.3，SNI可以加密。 所以，我告诉自己很棒！ 让我们看看它在cloudflare.com的TCP数据包中的样子
所以，我从cloudflare服务器的响应中捕获了一个"客户端问候"握手包。 我仍然可以用纯文本读取服务器名称。
因此，请注意您可以阅读的内容，因为这仍然不是匿名连接，因为中间人可以看到目标服务器名称。
因此，看起来SNI的加密需要额外的实现才能与TLSv1.3一起使用
以下文章描述了Cloudflare作为TLSv1.3的一部分提供的SNI加密。 但是，来自cloudlfare.com的所有HTTPs URL都可以在TLS v1.3下的TCP数据包中以纯文本格式读取
[https://blog.cloudflare.com/encrypted-sni/][3]
虽然这里有一些好的答案，但大多数都专注于浏览器导航。我在2018年写这篇文章，可能有人想知道移动应用程序的安全性。
对于移动应用程序，如果您控制应用程序的两端(服务器和应用程序)，只要您使用HTTPS，您就是安全的。 iOS或Android将验证证书并减轻可能的MiM攻击(这将是所有这些中唯一的弱点)。您可以通过HTTPS连接发送敏感数据，并在传输过程中对其进行加密。只需您的应用程序，服务器就会知道通过https发送的任何参数。
这里唯一的"可能"是，如果客户端或服务器感染了恶意软件，可以在将数据包装成https之前查看数据。但是，如果有人感染了这种软件，他们就可以访问数据，无论您使用什么来传输它。
此外，如果您正在构建ReSTful API，则浏览器泄漏和http referer问题通常会得到缓解，因为客户端可能不是浏览器，您可能没有人点击链接。
如果是这种情况，我建议oAuth2登录以获取持票令牌。在这种情况下，唯一的敏感数据将是初始凭证......无论如何，这应该在邮寄请求中
