HTTPS URL是否已加密？

1016

使用TLS / SSL（HTTPS）加密时是否对所有URL都进行了加密？我想知道，因为我希望在使用TLS / SSL（HTTPS）时隐藏所有URL数据。

如果TLS / SSL为您提供了完整的URL加密，那么我不必担心隐藏URL中的机密信息。

ssl  https  httprequest 
— 丹尼尔·基瓦蒂诺斯（Daniel Kivatinos）
source
76
无论如何，将机密数据放在URL中可能是一个坏主意。它也会在浏览器的地址中显示不好，还记得吗？如果碰巧看一下屏幕的任何人都可以看到他们的密码，人们就会不喜欢它。为什么您认为需要在URL中放入机密数据？
— jalf
43
URL也存储在浏览器历史记录和服务器日志中-如果我想将我的名称和密码存储在某个地方，则不会在这两个地方。
— Piskvor于
47
例如，假设我访问了https://somewhere_i_trust/ways_to_protest_against_the_government/。然后，URL包含机密数据，即我正在考虑抗议政府的建议。
— 史蒂夫·杰索普
42
当从本地（不是基于浏览器的）应用发出HTTP请求时，我在问自己这个问题。我猜想这可能会使移动应用程序开发人员感兴趣。在这种情况下，上面的注释（虽然为true）是无关紧要的（没有可见的url，没有浏览历史记录），根据我的理解，答案很简单：“是的，它是加密的”。
— DannyA 2012年
23
对于那些认为一旦成为​​HTTPS却没人知道要去哪里的人，请先阅读以下内容：由于SNI，服务器的主机名（例如example.com）仍然会泄漏。这与DNS完全无关，即使您不使用DNS或使用加密的DNS，也会发生泄漏。
— Pacerier，2015年

Answers:

911

是的，SSL连接在TCP层和HTTP层之间。客户端和服务器首先建立安全的加密TCP连接（通过SSL / TLS协议），然后客户端将通过该加密的TCP连接发送HTTP请求（GET，POST，DELETE ...）。

— 马克·诺瓦科夫斯基
source
98
仍然值得注意@Jalf在问题本身的评论中提到的内容。URL数据也将保存在浏览器的历史记录中，这可能是长期不安全的。
— Michael Ekstrand
20
不只是GET或POST。也可以是DELETE，PUT，HEAD或TRACE。
4
是的，这可能是浏览器历史记录的安全问题。但就我而言，我没有使用浏览器（同样，原始文章中也没有提到浏览器）。在本机应用程序的后台使用自定义https调用。这是确保应用程序服务器连接安全的简单解决方案。
— zingle-dingle
28
但是请注意，URL的DNS解析可能未加密。因此，嗅探您流量的人仍可能会看到您尝试访问的域。
— ChewToy
21
SNI破坏了URL的SSL加密的“主机”部分。您可以使用Wireshark自己对此进行测试。有一个SNI选择器，或者您可以在连接到远程主机时仅查看SSL数据包。
— cmouse 2014年
652

由于没有人提供电汇，这是一个。
服务器名称（URL的域部分）ClientHello以纯文本形式出现在数据包中。

下面显示了浏览器的请求：
https://i.stack.imgur.com/path/?some=parameters&go=here

客户您好SNI 有关 TLS版本字段的更多信息，请参见此答案（其中有3个-不是版本，每个字段都包含版本号！）

来自https://www.ietf.org/rfc/rfc3546.txt：

3.1。服务器名称指示

[TLS]没有为客户端提供一种机制来告知服务器它正在联系的服务器的名称。 客户可能希望提供此信息，以促进与服务器的安全连接，这些服务器在单个基础网络地址上托管着多个“虚拟”服务器。

为了提供服务器名称，客户端可以在（扩展的）客户端问候中包含类型为“ server_name”的扩展。


简而言之：

  • 如果使用SNI扩展名，则FQDN（URL的域部分）可以在数据包内以明文形式传输。ClientHello

  • 由于请求URL是HTTP（OSI第7层）内容，因此URL（/path/?some=parameters&go=here）的其余部分没有任何事务ClientHello，因此它将永远不会显示在TLS握手中（第4层或第5层）。建立安全 TLS通道后，稍后将在GET /path/?some=parameters&go=here HTTP/1.1HTTP请求中进行处理。


执行摘要

域名可以明文传输（如果在TLS握手中使用了SNI扩展名），但是URL（路径和参数）始终是加密的。


2019年3月更新

谢谢carlin.scott提出了这一点。

现在，可以通过此RFC提议草案对SNI扩展中的有效负载进行加密。此功能仅在TLS 1.3中存在（作为一种选择，并且要由两端实现），并且与TLS 1.2及以下版本不存在向后兼容性。

CloudFlare正在这样做，您可以在此处了解更多内部信息— 如果鸡肉必须在鸡蛋之前出现，您将鸡肉放在哪里？

实际上，这意味着它现在已经加密了，而不是以纯文本形式发送FQDN（如Wireshark捕获所示）。

注意：由于反向DNS查找可能仍会显示预期的目标主机，因此它比安全性更能解决隐私问题。

— 邪恶的
source
37
完美的答案，从A到Z都有完整的说明。我喜欢执行摘要。让我开心@evilSnobu
— oscaroscar，
4
完美的答案，支持！仍考虑客户端部分，因为浏览器历史记录可能是泄漏的。但是，对于传输层，URL参数已加密。
— 詹斯·克雷德勒
2
您可能想用TLS 1.3加密SNI扩展名的事实来更新此答案，而最大的CDN就是这样做的：blog.cloudflare.com/encrypted-sni 当然，数据包嗅探器仅可以对它进行反向DNS查找。您要连接的IP地址。
— carlin.scott
@evilSnobu，但用户名：密码部分用户名：password@domain.com是加密的，对不对？因此使用https在URL中传递敏感数据是安全的。
— Maksim Shamihulau，
1
它们在传输中进行了加密（传输），但是如果任一端（用户或服务器）将URL记录到纯文本文件中并且没有清除凭据，则这是另一种对话。
— evilSnobu
159

正如其他 答案已经指出的那样，https“ URL”确实是加密的。但是，解析域名时您的DNS请求/响应可能不是，当然，如果您使用的是浏览器，URL可能也会被记录下来。

— 扎克·史克里文娜（Zach Scrivena）
source
21
URL记录很重要，因为有Java hacks可以让一个完全不相关的站点测试给定URL是否在您的历史记录中。您可以通过在其中包含一个较长的随机字符串来使URL变得不可猜测，但是如果它是公共URL，则攻击者可以告诉它已被访问，并且如果其中包含一个简短的秘密，则攻击者可以蛮力地以合理的速度。
— 史蒂夫·杰索普
8
@SteveJessop，请提供指向“允许完全不相关的网站测试您的历史记录中是否存在给定URL的Java hacks”
— Pacerier 2014年
6
@Pacerier：当然是黑客约会，但是我当时谈论的是诸如stackoverflow.com/questions/2394890/…之类的东西。在2010年，对这些问题进行了调查并且对攻击进行了细化是一件大事，但是我目前还没有真正关注它。
— 史蒂夫·杰索普
2
@Pacerier：更多的例子：webdevwonders.com/...，webdevwonders.com/...
— 史蒂夫·杰索普
1
您可以将OpenDNS与它的加密DNS服务一起使用。我在Mac上使用它，但是发现Windows版本无法正常工作。不过那是前一阵子，所以现在可能行得通。对于Linux来说，还没有。opendns.com/about/innovations/dnscrypt
— SPRBRN
101

整个请求和响应都已加密，包括URL。

请注意，当您使用HTTP代理时，它知道目标服务器的地址（域），但不知道该服务器上的请求路径（即，请求和响应始终被加密）。

— 彼得·史蒂布兰妮
source
1
整个请求。主机名是明文发送的。其他所有内容均已加密。
— 山姆·瑟里
98

我同意先前的答案：

明确地说：

使用TLS，URL的第一部分（https://www.example.com/）在建立连接时仍然可见。第二部分（/ herearemygetparameters / 1/2/3/4）受TLS保护。

但是，有很多原因导致您不应该在GET请求中放置参数。

首先，正如其他人已经提到的：-通过浏览器地址栏泄漏-通过历史记录泄漏

除此之外，您还会通过http引荐网址泄漏URL：用户在TLS上看到站点A，然后单击指向站点B的链接。如果两个站点都在TLS上，则对站点B的请求将包含站点A中的完整URL。请求的参照参数。站点B的管理员可以从服务器B的日志文件中检索它。）

— 托比亚斯
source
3
@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。如果这是真的，那是非常糟糕的。这是真的托比亚斯吗？
— trusktr 2014年
9
@EJP，由于所有现代Web浏览器都使用SNI，因此可以看到该域。还可以从EFF中看到此图，该图表明任何人都可以看到您正在访问的站点的域。这与浏览器的可见性无关。这是关于窃听者可见的内容。
— Buge 2014年
10
@trusktr：浏览器不应从HTTPS页面发送Referer标头。这是HTTP规范的一部分。
— 马丁·盖斯勒
8
@MartinGeisler，关键字是“应该”。浏览器不太关心“应该”（而不是“必须”）。在您自己的链接中：“强烈建议用户选择发送“引荐来源网址”字段。例如，浏览器客户端可以具有一个用于公开/匿名浏览的切换开关，分别启用 /禁用发送引荐来源信息”。操作，这正是Chrome所做的。即使您处于隐身模式， Chrome还是会泄漏Referrer 。
— Pacerier，2015年
48

马克·诺瓦科夫斯基（Marc Novakowski）的有用答案的补充-URL存储在服务器上的日志中（例如，存储在/ etc / httpd / logs / ssl_access_log中），因此，如果您不希望服务器将信息保存更长的时间，术语，请勿将其放在URL中。

— 罗德里·库萨克（Rhodri Cusack）
source
34

是的，没有。

服务器地址部分未加密，因为它用于建立连接。

将来，使用加密的SNI和DNS可能会改变这种情况，但是截至2018年，这两种技术已不再普遍使用。

路径，查询字符串等已加密。

对于GET请求，请注意，用户仍然可以将URL剪切并粘贴到位置栏中，并且您可能不希望在其中放置任何人都可以看到屏幕的机密信息。

— 肥皂盒
source
8
想要对此+1，但是我发现“是与否”具有误导性-您应该更改它，以指出服务器名称将使用DNS进行解析而不进行加密。
— 劳伦斯·多尔
7
以我的理解，OP在正确的意义上使用了URL一词。我认为这个答案更具误导性，因为它并没有明确区分URL中的主机名和DNS解析中的主机名。
— 纪尧姆
4
网址已加密。HTTP事务的每个方面都经过加密。不只是“其他”。期。-1。
— user207421
4
@EJP，但是DNS查找确实使用URL某一部分的内容，因此对于非技术人员而言，整个URL不会被加密。仅使用Google.com查找非技术性内容的非技术人员不知道数据最终位于何处或如何处理。该域是用户访问的URL的一部分，并未100％加密，因为作为攻击者，我可以嗅探到他正在访问哪个站点。仅URL的/ path会固有地加密给外行（无关紧要）。
— trusktr 2014年
6
@EJP，@trusktr，@劳伦斯，@纪尧姆。你们所有人都错了。这与DNS无关。SNI“ 作为TLS协商的一部分发送虚拟域的名称 ”，因此，即使您不使用DNS或DNS被加密，嗅探器仍然可以看到您的请求的主机名。
— Pacerier，2015年
9

监视流量的第三方也可以通过检查您的流量并将其与其他用户访问该站点的流量进行比较来确定访问的页面。例如，如果一个站点上只有2个页面，一个页面比另一个页面大得多，那么比较数据传输的大小就会知道您访问了哪个页面。有几种方法可以将其隐藏给第三方，但它们不是正常的服务器或浏览器行为。例如，请参见SciRate上的这篇论文，网址为https://scirate.com/arxiv/1403.0297。

通常，其他答案是正确的，尽管实际上本文显示可以很有效地确定访问的页面（即URL）。

— b
source
这实际上仅在很小的网站上才是可行的，在这种情况下，网站的主题/基调/性质在每个页面上可能仍然大致相同。
— 卡梅隆
5
从我的引文中可以得出：“我们针对超过6000个网页进行了流量分析攻击，涵盖10个行业领先的网站的HTTPS部署，涉及医疗保健，金融，法律服务和流媒体视频等领域。我们的攻击可识别其中的各个页面同一个网站，其准确度为89％”。您对可行性的结论似乎是错误的。
— pbhj
2
对于对阅读此类漏洞感兴趣的人，这些类型的攻击通常称为旁道攻击。
— Dan Bechard
7

您也不能总是依靠完整URL的私密性。例如，有时在企业网络中，像公司PC这样的提供的设备都配置了额外的“受信任”根证书，以便您的浏览器可以安静地信任对HTTPS流量的代理（中间人）检查。这意味着公开了完整的URL供检查。通常将其保存到日志中。

此外，您的密码也会被公开并可能被记录下来，这是使用一次性密码或经常更改密码的另一个原因。

最后，如果未进行其他加密，则请求和响应内容也将公开。

Checkpoint此处介绍了一种检查设置的示例。也可以通过这种方式设置使用提供的PC的旧式“ Internetcafé”。

— 唐·吉利斯
source
6

链接到我对重复问题的回答。该URL不仅在浏览器历史记录中可用，而且在服务器端日志中也将作为HTTP Referer标头发送，如果您使用第三方内容，则将该URL暴露给您控制之外的源。

— 乔什·伯克
source
提供第三方呼叫也是HTTPS，尽管这不是问题吧？
— 利亚姆
3
它会使用第三方证书进行加密，以便他们可以看到该网址
— JoshBerke，2016年
5

现在是2019年，并且TLS v1.3已发布。根据Cloudflare的说法，借助TLS v1.3，可以对SNI进行加密。所以，我告诉自己太好了！让我们看一下它在cloudflare.com的TCP数据包中的外观。因此，我从使用Google Chrome作为浏览器和Wireshark作为数据包嗅探器的cloudflare服务器的响应中捕获了一个“客户端问候”握手数据包。我仍然可以在Client hello数据包中以纯文本格式读取服务器名称。

在此处输入图片说明

因此，请注意您可以阅读的内容，因为这仍然不是匿名连接。客户端和服务器之间的中间件可以记录客户端请求的每个域。

因此，看起来SNI的加密需要其他实现才能与TLSv1.3一起使用

下面的文章介绍了Cloudflare作为TLSv1.3的一部分提供的SNI的加密。但是，在TLS v1.3下，cloudflare.com的所有HTTP URL均以纯文本形式出现在TCP数据包中

[ https://blog.cloudflare.com/encrypted-sni/][3]

— 尼古拉斯·奎里纳特
source
“ 可以对SNI 进行加密”- 这才是关键。在使用当前的Google Chrome浏览器检查cloudflare.com/ssl/encrypted-sni时说：“您的浏览器在访问此页面时未加密SNI。” 探戈需要两个人……
— Piskvor在
显然，当前的Firefox 可以执行ESNI，但默认情况下处于禁用状态：您需要将network.security.esni.enabled，设置network.trr.mode为2（当前将DoH解析器设置为CloudFlare），然后重新启动浏览器（原文如此！）；那么它将使用ESNI-域的基础架构支持的位置。有关详细信息，请参阅blog.mozilla.org/security/2018/10/18/…。
— Piskvor在
3

是的，没有。

实际的URL已加密，这意味着某人无法分辨出您访问的网站上的确切网页。但是，TLS标头包含您正在访问的服务器的主机名（例如，www.quora.com）未加密。DNS也几乎永远不会被加密，并且还会泄漏您正在访问的主机名。默认情况下，此DNS查询几乎始终针对您ISP的服务器，因此，它们可以通过将DNS请求嗅探到其他DNS服务器，或针对自己的DNS服务器进行记录来轻松查看您访问的每个网站的主机名。

但是，如果您担心是否有人可以找到您正在访问哪个网站，这还不够。HTTPS在OSI第4层上运行，并在该级别上加密所有数据，但较低的级别留给了承载它的网络。仍然有人可以只追踪OSI层3上的流量的路径和目的地。这意味着嗅探您的流量的人可以找到IP地址，并通过扩展找到您正在访问的网站的域名。

更糟糕的是，您第一次（以及随后的某些时间，具体取决于清除DNS缓存的方式/时间）可能会将未加密的DNS查询发送到任何DNS服务器，以请求HTTPS目标URL的IP地址（同样，通过默认情况下，通常是您的ISP的服务器）。任何能够访问您的DNS服务器路径上的流量的人都可以嗅探此查询。

如果您正在寻求高标准的隐私，则需要使用受信任的加密VPN和/或加密代理服务来补充HTTPS。您也可以调查DNSSEC来保护DNS查询。此服务必须是可信赖的，因为它们可以轻松地执行上述对流量来源和目的地的跟踪。

— Himanshu Patel
source
2

尽管这里已经有一些不错的答案，但大多数答案都集中在浏览器导航上。我在2018年撰写本文，可能有人想知道移动应用程序的安全性。

对于移动应用程序，如果您同时控制应用程序的两端（服务器和应用程序），则只要使用HTTPS 便是安全的。iOS或Android将验证证书并缓解可能的MiM攻击（这将是所有这方面的唯一弱点）。您可以通过HTTPS连接发送敏感数据，该数据将在传输过程中进行加密。仅您的应用程序和服务器将知道通过https发送的所有参数。

唯一的“可能”是客户端或服务器感染了恶意软件，这些恶意软件可以在将数据包装到https中之前先查看数据。但是，如果有人感染了这种软件，则无论您使用什么方式传输数据，他们都可以访问该数据。

— 里卡多BRGWeb
source
1

此外，如果您正在构建ReSTful API，则大多数缓解了浏览器泄漏和http引用问题，因为客户端可能不是浏览器，并且可能没有人单击链接。

如果是这种情况，我建议您使用oAuth2登录以获取承载令牌。在这种情况下，唯一敏感的数据将是初始凭证...无论如何，该凭证都应该在发布请求中

— 克里斯·鲁特里奇
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.