HTTPS URL 是否加密？
使用 TLS/SSL (HTTPS) 加密时是否所有 URL 均已加密？ 我想知道，因为我希望在使用 TLS/SSL (HTTPS) 时隐藏所有 URL 数据。
如果 TLS/SSL 为您提供全面的 URL 加密，那么我就不必担心隐藏 URL 中的机密信息。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
是的，SSL连接是在TCP层和HTTP层之间。 客户端和服务器首先建立安全加密的 TCP 连接（通过 SSL/TLS 协议），然后客户端将通过该加密的 TCP 连接发送 HTTP 请求（GET、POST、DELETE...）。
但请注意（也如注释中所述），URL 的域名部分在 TLS 协商的第一部分期间以明文形式发送。 这样，服务器的域名就可以被嗅探到了。 但不是 URL 的其余部分。
Yes, the SSL connection is between the TCP layer and the HTTP layer. The client and server first establish a secure encrypted TCP connection (via the SSL/TLS protocol) and then the client will send the HTTP request (GET, POST, DELETE...) over that encrypted TCP connection.
Note however (as also noted in the comments) that the domain name part of the URL is sent in clear text during the first part of the TLS negotiation. So, the domain name of the server can be sniffed. But not the rest of the URL.
由于没有人提供有线捕获，这是一个。
服务器名称（URL 的域部分）以纯文本形式显示在
ClientHello数据包中。下面显示了浏览器请求：
https://i.stack.imgur.com/path/?some=parameters&go=here请参阅此答案，了解有关 TLS 版本字段的更多信息（其中有 3 个 - 不是版本，每个字段都包含版本号） ！）
来自https://www.ietf.org/rfc/rfc3546.txt：
简而言之：
FQDN（URL 的域部分）可以以明文形式传输如果使用 SNI 扩展，则位于
ClientHello数据包内/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 提出这一问题。
SNI 扩展中的有效负载现在可以通过 进行加密此 RFC 提案草案。 此功能仅存在于 TLS 1.3 中（作为一个选项，由两端来实现），并且不向后兼容 TLS 1.2 及更低版本。
CloudFlare 正在这样做，您可以在此处阅读有关内部结构的更多信息 —
如果先有鸡先有蛋，你把鸡放在哪里？
实际上这意味着现在，FQDN 不再以纯文本形式传输（如 Wireshark 捕获显示的那样），而是已加密。
注意：这比安全问题更能解决隐私问题，因为反向 DNS 查找无论如何都可能会泄露预期的目标主机。
2020 年 9 月更新
现在有一个 RFC 草案用于加密整个 Client Hello 消息，而不仅仅是 SNI 部分：
https://datatracker.ietf.org/doc/draft- ietf-tls-esni/?include_text=1
在撰写本文时，此浏览器支持非常有限。
Since nobody provided a wire capture, here's one.
Server Name (the domain part of the URL) is presented in the
ClientHellopacket, in plain text.The following shows a browser request to:
https://i.stack.imgur.com/path/?some=parameters&go=hereSee this answer for more on TLS version fields (there are 3 of them - not versions, fields that each contain a version number!)
From https://www.ietf.org/rfc/rfc3546.txt:
In short:
FQDN (the domain part of the URL) MAY be transmitted in clear inside the
ClientHellopacket if SNI extension is usedThe rest of the URL (
/path/?some=parameters&go=here) has no business being insideClientHellosince the request URL is a HTTP thing (OSI Layer 7), therefore it will never show up in a TLS handshake (Layer 4 or 5). That will come later on in aGET /path/?some=parameters&go=here HTTP/1.1HTTP request, AFTER the secure TLS channel is established.EXECUTIVE SUMMARY
Domain name MAY be transmitted in clear (if SNI extension is used in the TLS handshake) but URL (path and parameters) is always encrypted.
MARCH 2019 UPDATE
Thank you carlin.scott for bringing this one up.
The payload in the SNI extension can now be encrypted via this draft RFC proposal. This capability only exists in TLS 1.3 (as an option and it's up to both ends to implement it) and there is no backwards compatibility with TLS 1.2 and below.
CloudFlare is doing it and you can read more about the internals here —
If the chicken must come before the egg, where do you put the chicken?
In practice this means that instead of transmitting the FQDN in plain text (like the Wireshark capture shows), it is now encrypted.
NOTE: This addresses the privacy aspect more than the security one since a reverse DNS lookup MAY reveal the intended destination host anyway.
SEPTEMBER 2020 UPDATE
There's now a draft RFC for encrypting the entire Client Hello message, not just the SNI part:
https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1
At the time of writing this browser support is VERY limited.
作为 其他 answers已经指出，https“URL”确实是加密的。 但是，您在解析域名时的 DNS 请求/响应可能不会被记录，当然，如果您使用浏览器，您的 URL 也可能会被记录。
As the other answers have already pointed out, https "URLs" are indeed encrypted. However, your DNS request/response when resolving the domain name is probably not, and of course, if you were using a browser, your URLs might be recorded too.
我同意前面的答案：
明确地说：
使用 TLS，URL 的第一部分 (https://www.example .com/）在建立连接时仍然可见。 第二部分（/herearemygetparameters/1/2/3/4）受 TLS 保护。
然而，有很多原因导致您不应该在 GET 请求中添加参数。
首先，正如其他人已经提到的：
- 通过浏览器地址栏泄露
- 通过历史记录泄漏
除了通过 http 引用程序泄漏 URL 之外：用户在 TLS 上看到站点 A，然后单击指向站点 B 的链接。如果两个站点都在 TLS 上，则对站点 B 的请求将包含完整的 URL来自请求的referer 参数中的站点A。 站点 B 的管理员可以从服务器 B 的日志文件中检索它。）
I agree with the previous answers:
To be explicit:
With TLS, the first part of the URL (https://www.example.com/) is still visible as it builds the connection. The second part (/herearemygetparameters/1/2/3/4) is protected by TLS.
However there are a number of reasons why you should not put parameters in the GET request.
First, as already mentioned by others:
- leakage through browser address bar
- leakage through history
In addition to that you have leakage of URL through the http referer: user sees site A on TLS, then clicks a link to site B. If both sites are on TLS, the request to site B will contain the full URL from site A in the referer parameter of the request. And admin from site B can retrieve it from the log files of server B.)
整个请求和响应都被加密，包括 URL。
请注意，当您使用 HTTP 代理时，它知道目标服务器的地址（域），但不知道该服务器上的请求路径（即请求和响应始终加密）。
Entire request and response is encrypted, including URL.
Note that when you use a HTTP Proxy, it knows the address (domain) of the target server, but doesn't know the requested path on this server (i.e. request and response are always encrypted).
是和不是。
服务器地址部分未加密，因为它用于建立连接。
未来，加密的 SNI 和 DNS 可能会改变这种情况，但截至 2018 年，这两种技术尚未得到普遍使用。
路径、查询字符串等均已加密。
请注意，对于 GET 请求，用户仍然可以从地址栏中剪切并粘贴 URL，并且您可能不希望将机密信息放在那里，任何人看着屏幕都可以看到。
Yes and no.
The server address portion is NOT encrypted since it is used to set up the connection.
This may change in future with encrypted SNI and DNS but as of 2018 both technologies are not commonly in use.
The path, query string etc. are encrypted.
Note for GET requests the user will still be able to cut and paste the URL out of the location bar, and you will probably not want to put confidential information in there that can be seen by anyone looking at the screen.
Marc Novakowski 的有用答案的补充 - URL 存储在服务器上的日志中（例如，在 /etc/httpd/logs/ssl_access_log 中），因此如果您不希望服务器长时间维护信息术语，不要将其放在 URL 中。
An addition to the helpful answer from Marc Novakowski - the URL is stored in the logs on the server (e.g., in /etc/httpd/logs/ssl_access_log), so if you don't want the server to maintain the information over the longer term, don't put it in the URL.
现在已经是 2019 年了，TLS v1.3 已经发布。 根据 Cloudflare 的说法，服务器名称指示（SNI 又名主机名）可以通过 TLS v1.3 进行加密。 于是，我告诉自己太好了！ 让我们看看它在 cloudflare.com 的 TCP 数据包中是什么样子
因此，我从使用 Google Chrome 作为浏览器的 cloudflare 服务器的响应中捕获了一个“客户端问候”握手数据包。 wireshark 作为数据包嗅探器。 我仍然可以在客户端问候数据包中以纯文本形式读取主机名，如下所示。 它没有加密。
因此，请注意您可以阅读的内容，因为这仍然不是匿名连接。 客户端和服务器之间的中间件应用程序可以记录客户端请求的每个域。
因此，SNI 的加密似乎需要额外的实现才能与
2020 年 6 月更新的 TLSv1.3 配合使用：
看起来加密的 SNI 是由浏览器发起的。 Cloudflare 有一个页面供您检查浏览器是否支持加密 SNI：
https://www.cloudflare .com/ssl/encrypted-sni/
目前，我认为 Google chrome 不支持它。 您可以在 Firefox 中手动激活加密 SNI。 当我出于某种原因尝试时，它并没有立即起作用。 我重新启动了 Firefox 两次，然后它才起作用：
在 URL 字段中键入：about:config。
检查 network.security.esni.enabled 是否为 true。
清除缓存/重新启动
转到我之前提到的网站。
正如您所看到的，VPN 服务对于那些想要确保咖啡店老板不会记录人们访问的网站列表的人来说仍然很有用。
It is now 2019 and the TLS v1.3 has been released. According to Cloudflare, the server name indication (SNI aka the hostname) can be encrypted thanks to TLS v1.3. So, I told myself great! Let's see how it looks within the TCP packets of cloudflare.com
So, I caught a "client hello" handshake packet from a response of the cloudflare server using Google Chrome as browser & wireshark as packet sniffer. I still can read the hostname in plain text within the Client hello packet as you can see below. It is not encrypted.
So, beware of what you can read because this is still not an anonymous connection. A middleware application between the client and the server could log every domain that are requested by a client.
So, it looks like the encryption of the SNI requires additional implementations to work along with TLSv1.3
UPDATE June 2020:
It looks like the Encrypted SNI is initiated by the browser. Cloudflare has a page for you to check if your browser supports Encrypted SNI:
https://www.cloudflare.com/ssl/encrypted-sni/
At this point, I think Google chrome does not support it. You can activate Encrypted SNI in Firefox manually. When I tried it for some reason, it didn't work instantly. I restarted Firefox twice before it worked:
Type: about:config in the URL field.
Check if network.security.esni.enabled is true.
Clear your cache / restart
Go to the website, I mentioned before.
As you can see VPN services are still useful today for people who want to ensure that a coffee shop owner does not log the list of websites that people visit.
监控流量的第三方也可以通过检查您的流量并将其与其他用户访问该网站时的流量进行比较来确定访问的页面。 例如，如果一个网站上只有 2 个页面，其中一个页面比另一个页面大得多，那么通过比较数据传输的大小就可以知道您访问的是哪个页面。 有一些方法可以对第三方隐藏此行为，但它们不是正常的服务器或浏览器行为。 例如，请参阅 SciRate 的这篇论文，https://scirate.com/arxiv/1403.0297。
一般来说，其他答案是正确的，尽管本文表明可以非常有效地确定访问的页面（即 URL）。
A third-party that is monitoring traffic may also be able to determine the page visited by examining your traffic an comparing it with the traffic another user has when visiting the site. For example if there were 2 pages only on a site, one much larger than the other, then comparison of the size of the data transfer would tell which page you visited. There are ways this could be hidden from the third-party but they're not normal server or browser behaviour. See for example this paper from SciRate, https://scirate.com/arxiv/1403.0297.
In general other answers are correct, practically though this paper shows that pages visited (ie URL) can be determined quite effectively.
您也不能总是依赖完整 URL 的隐私。 例如，有时在企业网络上会出现这种情况，提供的设备（例如您公司的 PC）配置有额外的“受信任”根证书，以便您的浏览器可以悄悄地信任 https 流量的代理（中间人）检查。 这意味着完整的 URL 会公开以供检查。 这通常保存到日志中。
此外，您的密码也会暴露并可能被记录，这是使用一次性密码 或经常更改您的密码。
最后，如果不进行其他加密，请求和响应内容也会暴露。
此处的检查点描述了检查设置的一个示例。 使用提供的个人电脑的老式“网吧”也可以通过这种方式建立。
You can not always count on privacy of the full URL either. For instance, as is sometimes the case on enterprise networks, supplied devices like your company PC are configured with an extra "trusted" root certificate so that your browser can quietly trust a proxy (man-in-the-middle) inspection of https traffic. This means that the full URL is exposed for inspection. This is usually saved to a log.
Furthermore, your passwords are also exposed and probably logged and this is another reason to use one time passwords or to change your passwords frequently.
Finally, the request and response content is also exposed if not otherwise encrypted.
One example of the inspection setup is described by Checkpoint here. An old style "internet café" using supplied PC's may also be set up this way.
尽管这里已经有一些很好的答案，但其中大多数都集中在浏览器导航上。 我在 2018 年写这篇文章，可能有人想了解移动应用程序的安全性。
对于移动应用，如果您控制应用的两端（服务器和应用），只要使用 HTTPS 您就是安全的。 iOS 或 Android 将验证证书并减轻可能的 MiM 攻击（这将是这一切中唯一的弱点）。 您可以通过 HTTPS 连接发送敏感数据，这些数据将在传输过程中进行加密。 只有您的应用程序和服务器会知道通过 https 发送的任何参数。
这里唯一的“可能”是客户端或服务器感染了恶意软件，这些软件可以在数据封装在 https 中之前看到数据。 但是，如果有人感染了此类软件，他们就可以访问数据，无论您使用什么方式传输数据。
Althought there are some good answers already here, most of them are focusing in browser navigation. I'm writing this in 2018 and probably someone wants to know about the security of mobile apps.
For mobile apps, if you control both ends of the application (server and app), as long as you use HTTPS you're secure. iOS or Android will verify the certificate and mitigate possible MiM attacks (that would be the only weak point in all this). You can send sensitive data through HTTPS connections that it will be encrypted during transport. Just your app and the server will know any parameters sent through https.
The only "maybe" here would be if client or server are infected with malicious software that can see the data before it is wrapped in https. But if someone is infected with this kind of software, they will have access to the data, no matter what you use to transport it.
虽然您已经有了很好的答案，但我真的很喜欢这个网站上的解释： https://https.cio.gov/faq/#what-information-does-https-protect
简而言之：使用 HTTPS 隐藏：
While you already have very good answers, I really like the explanation on this website: https://https.cio.gov/faq/#what-information-does-https-protect
in short: using HTTPS hides:
链接到我对重复问题的回答。 URL 不仅在浏览器历史记录、服务器端日志中可用，而且还作为 HTTP Referer 标头发送，如果您使用第三方内容，会将 URL 暴露给您无法控制的来源。
Linking to my answer on a duplicate question. Not only is the URL available in the browsers history, the server side logs but it's also sent as the HTTP Referer header which if you use third party content, exposes the URL to sources outside your control.
此外，如果您正在构建 ReSTful API，则浏览器泄漏和 http 引用问题大部分都会得到缓解，因为客户端可能不是浏览器，并且可能没有人点击链接。
如果是这种情况，我建议使用 oAuth2 登录来获取不记名令牌。 在这种情况下，唯一的敏感数据是初始凭据......无论如何，它可能应该在发布请求中
Additionally, if you're building a ReSTful API, browser leakage and http referer issues are mostly mitigated as the client may not be a browser and you may not have people clicking links.
If this is the case I'd recommend oAuth2 login to obtain a bearer token. In which case the only sensitive data would be the initial credentials...which should probably be in a post request anyway