HTTPS URL是否已加密？

Question

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

如果TLS / SSL为您提供全面的URL加密，那么我不必担心会从网址中隐藏机密信息。

Answer 1

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

Answer 2

由于没有人提供线捕获，所以这是一个 服务器名称（网址的域名部分）显示在ClientHello数据包中，纯文本。

以下显示浏览器请求：
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]不提供客户端告知服务器的机制   它正在联系的服务器的名称。可能需要   客户提供此信息以方便安全   连接到托管多个“虚拟”服务器的服务器   单个底层网络地址。

     

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

简而言之：

• 如果使用SNI扩展名，则ClientHello数据包中的FQDN（网址的域名部分）可能 清除

• 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 安全 TLS频道已建立。

执行摘要

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

2019年3月更新

感谢carlin.scott提出这个问题。

现在可以通过this draft RFC proposal加密SNI扩展中的有效负载。此功能仅存在于TLS 1.3中（作为选项，它可以实现两端），并且与TLS 1.2及更低版本没有向后兼容性。

CloudFlare正在这样做，你可以在这里阅读更多关于内部的内容 - If the chicken must come before the egg, where do you put the chicken?

实际上，这意味着它不是以纯文本形式传输FQDN（如Wireshark捕获节目），而是加密。

注意：这解决了隐私问题，而不是安全问题，因为反向DNS查找无论如何都可能会显示目标主机。

Answer 3

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

Answer 4

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

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

Answer 5

我同意以前的答案：

明确：

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

但是，为什么不应该在GET请求中放置参数有很多原因。

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

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

Answer 6

Marc Novakowski的有用答案的补充 - URL存储在服务器的日志中（例如，在/ etc / httpd / logs / ssl_access_log中），因此如果您不希望服务器维护信息从长远来看，请不要将其放在网址中。

Answer 7

是和否。

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

将来可能会使用加密的SNI和DNS进行更改，但截至2018年，两种技术都不常用。

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

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

Answer 8

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

一般来说，其他答案都是正确的，但实际上这篇论文表明，访问过的网页（即网址）可以非常有效地确定。

Answer 9

在ASCII上链接到我的答案。不仅在浏览器历史记录中提供了URL，服务器端日志，而且它也作为HTTP Referer标头发送，如果您使用第三方内容，则将URL公开给您控制之外的源。

Answer 10

您也不能始终依赖完整网址的隐私权。例如，正如企业网络上的情况一样，像公司PC这样的提供的设备配置了额外的“可信”根证书，这样您的浏览器就可以安静地信任https流量的代理（中间人）检查。这意味着公开了完整的URL以供检查。这通常保存到日志中。

此外，您的密码也会暴露并可能已记录，这是使用one time passwords或经常更改密码的另一个原因。

最后，如果没有加密，请求和响应内容也会被公开。

Checkpoint here描述了检查设置的一个示例。使用提供的PC的旧式“网吧”也可以这种方式设置。

Answer 11

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

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

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

Answer 12

现在是2019年，并且TLS v1.3已发布。根据cloudflare的说法，借助TLS v1.3，可以对SNI进行加密。所以，我告诉自己太好了！让我们看看它在cloudflare.com的TCP数据包中如何显示 因此，我从cloudflare服务器的响应中捕获到一个“客户端问候”握手数据包。我仍然可以用纯文本格式读取服务器名称。

因此，请注意您可以阅读的内容，因为它仍然不是匿名连接，因为中介可以看到目标服务器名称。

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

以下文章描述了Cloudflare作为TLSv1.3的一部分提供的SNI的加密。但是，可以从TLS v1.3

下的TCP数据包中以纯文本格式读取cloudlfare.com上的所有HTTPs URL。

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

Answer 13

尽管您已经获得了很好的答案，但我非常喜欢此网站上的说明：https://https.cio.gov/faq/#what-information-does-https-protect

简而言之：使用HTTPS隐藏：

• HTTP方法
• 查询参数
• POST正文（如果有）
• 请求标头（包括cookie）
• 状态码

Answer 14

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

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

Answer 15

是，不是。

实际的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查询。此服务必须是可信任的，因为它们可以轻松执行上述流量来源和目的地的跟踪。