使用TLS/SSL (HTTPS)加密时,所有url都加密了吗?我想知道,因为我想在使用TLS/SSL (HTTPS)时隐藏所有URL数据。

如果TLS/SSL提供了URL的全部加密,那么我就不必担心从URL中隐藏机密信息。


当前回答

此外,如果您正在构建一个ReSTful API,浏览器泄漏和http引用程序问题将在很大程度上得到缓解,因为客户端可能不是浏览器,您可能没有人点击链接。

如果是这种情况,我建议登录oAuth2以获得一个不记名令牌。在这种情况下,唯一的敏感数据将是初始凭证……无论如何,这应该在post请求中

其他回答

此外,如果您正在构建一个ReSTful API,浏览器泄漏和http引用程序问题将在很大程度上得到缓解,因为客户端可能不是浏览器,您可能没有人点击链接。

如果是这种情况,我建议登录oAuth2以获得一个不记名令牌。在这种情况下,唯一的敏感数据将是初始凭证……无论如何,这应该在post请求中

我同意前面的答案:

明确地说:

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

然而,您不应该在GET请求中放置参数的原因有很多。

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

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

是的,SSL连接是在TCP层和HTTP层之间。客户端和服务器端首先建立一个安全的加密TCP连接(通过SSL/TLS协议),然后客户端通过加密的TCP连接发送HTTP请求(GET, POST, DELETE…)

但是请注意(在评论中也提到了),URL的域名部分在TLS协商的第一部分以明文形式发送。因此,可以嗅出服务器的域名。但不是URL的其余部分。

正如其他答案已经指出的,https“url”确实是加密的。然而,解析域名时您的DNS请求/响应可能不是,当然,如果您使用浏览器,您的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层)。some=parameters&go=here HTTP/1.1 HTTP请求,安全TLS通道建立后。


执行概要

域名可以清晰传输(如果在TLS握手中使用SNI扩展),但URL(路径和参数)始终是加密的。


2019年3月更新

谢谢你,carlin。斯科特,谢谢你提起这件事。

SNI扩展中的有效载荷现在可以通过RFC提案草案进行加密。此功能仅存在于TLS 1.3中(作为一个选项,由两端实现),并且不向后兼容TLS 1.2及以下版本。

CloudFlare正在做这件事,你可以在这里阅读更多关于内部的信息 如果先有鸡后有蛋,你会把鸡放在哪里?

实际上,这意味着FQDN不再以纯文本形式传输(如Wireshark捕获的内容所示),而是被加密了。

注意:这解决了隐私方面的问题,而不是安全方面的问题,因为反向DNS查找可能会暴露预期的目标主机。

2020年9月更新

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

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