小开

最佳答案

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

但请注意（如评论中所述），URL的域名部分在TLS协商的第一部分期间以明文形式发送。因此，可以嗅探服务器的域名。但不是URL的其余部分。

小开

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

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

小开

是也不是。

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

加密SNI和DNS可能会在未来发生变化，但截至2018年，这两种技术都不常用。

路径、查询字符串等被加密。

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

小开

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

小开

除了Marc Novakowski的有用回答之外，URL存储在服务器上的日志中（例如，在 /etc/httpd/logs/ssl_access_log中），因此如果您不希望服务器长期维护信息，请不要将其放在URL中。

小开

我同意前面的回答：

明确地说：

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

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

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

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

小开

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

一般来说，其他答案是正确的，实际上，尽管本文表明访问的页面（即URL）可以非常有效地确定。

小开

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

小开

因为没有人提供电线捕获，这里有一个。
服务器名称（URL的域部分）显示在纯文本中的ClientHello数据包中。

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

看到这个答案了解有关TLS版本字段的更多信息（其中有3个-不是版本，每个字段都包含版本号！）

从https://www.ietf.org/rfc/rfc3546.txt：

3.1。服务器名称指示
[TLS]不提供客户端告诉服务器的机制它正在联系的服务器的名称。它可能需要客户提供此信息以促进安全连接到托管多个“虚拟”服务器的服务器单个底层网络地址。

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

简而言之：

如果使用SNI扩展，FQDN（URL的域部分）五月将在ClientHello数据包内传输以明确
URL（/path/?some=parameters&go=here）的其余部分与ClientHello无关，因为请求URL是HTTP的东西（OSI第7层），因此它永远不会在TLS握手（第4层或第5层）中显示。稍后将在GET /path/?some=parameters&go=here HTTP/1.1 HTTP请求中出现，之后安全 TLS通道建立。

内容提要

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

2019年3月更新

谢谢你carlin.scott把这个拿出来。

SNI扩展中的有效负载现在可以通过这份RFC提案草案加密。此功能仅存在于TLS 1.3中（作为一个选项，由两端来实现），并且与TLS 1.2及以下版本没有向后兼容性。

CloudFlare正在这样做，你可以在这里阅读更多关于内部的信息-如果鸡必须先于蛋，你把鸡放在哪里？

实际上，这意味着不再以纯文本形式传输FQDN（如Wireshark捕获所示），而是对其进行加密。

注：这比安全方面更能解决隐私方面的问题，因为反向DNS查找无论如何都可能会显示预期的目标主机。

2020年9月更新

现在有一个用于加密整个Client Hello消息的RFC草案，而不仅仅是SNI部分：https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1

在撰写本文时，此浏览器支持非常有限。

小开

您也不能总是指望完整URL的隐私。例如，有时在企业网络上，提供的设备（如您的公司PC）配置了额外的“受信任”根证书，以便您的浏览器可以悄悄地信任代理（中间人）检查https流量。这意味着完整的URL被公开以供检查。这通常保存到日志中。

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

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

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

小开

尽管这里已经有了一些很好的答案，但其中大多数都专注于浏览器导航。我在2018年写这篇文章，可能有人想知道移动应用程序的安全性。

对于移动应用程序，如果你控制应用程序的两端（服务器和应用程序），只要你使用HTTPS你很安全。iOS或Android将验证证书并减轻可能的MiM攻击（这将是所有这一切中唯一的弱点）。你可以通过HTTPS连接发送敏感数据，它将被加密在运输。只有你的应用程序和服务器会知道通过https发送的任何参数。

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

小开

此外，如果您正在构建一个ReSTful API，浏览器泄漏和超文本传输协议问题大多会得到缓解，因为客户端可能不是浏览器，也可能没有人点击链接。

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

小开

现在是2019年，TLS v1.3已经发布。根据Cloudflare的说法，服务器名称指示（SNI也就是主机名）可以通过TLS v1.3进行加密。所以，我告诉自己太好了！让我们看看它在cloudflare.com的TCP数据包中的样子所以，我从使用GoogleChrome作为浏览器和wireshark作为数据包嗅探器的Cloudflare服务器的响应中捕获了一个“客户端你好”握手数据包。我仍然可以在客户端你好数据包中以纯文本形式读取主机名，如下所示。它没有加密。

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

因此，SNI的加密似乎需要额外的实现才能与TLSv1.3一起工作

2020年6月更新：看起来加密SNI是由浏览器启动的。Cloudflare有一个页面供您检查您的浏览器是否支持加密SNI：

https://www.cloudflare.com/ssl/encrypted-sni/

在这一点上，我认为Google chrome不支持它。您可以手动在Firefox中激活加密SNI。当我出于某种原因尝试时，它没有立即工作。我重新启动了Firefox两次才起作用：

URL字段中的Type： about： config。

检查network.security.esni.enabled是否正确。清除缓存/重新启动

去网站，我之前提到过。

正如您所看到的，对于想要确保咖啡店老板不记录人们访问的网站列表的人来说，VPN服务今天仍然很有用。

小开

虽然你已经有了很好的答案，但我真的很喜欢这个网站上的解释：https://https.cio.gov/faq/#what-information-does-https-protect

简而言之：使用HTTPS隐藏：

http方法
查询参数
POST主体（如果存在）
请求标头（包括cookie）
状态码