假设我在浏览器中键入此内容

https://www.mysite.com/getsecret?username=alice&password=mysecret


，攻击者正在监视从我到ISP的所有流量。

HTTPS保护哪些信息？网址显示了吗？

HTTPS是否提供URL的完整性？

我尝试查看各种HTTPS文章和TLS规范，但无法弄清楚。

[编辑：]可以，只要仅显示服务器域名即可。但是，不应显示?username=alice&password=mysecret的任何部分。

评论

还可以看到我的公司可以看到我去过哪些HTTPS网站吗？ -不是重复的，但可能是相关的。
相关：通配符证书是否隐藏了URL而不被访问？

#1 楼

HTTPS协议等效于通过SSL或TLS连接（通过TCP）使用HTTP。

，因此，首先向服务器打开了TCP连接（在端口443上）。这通常足以向攻击者显示服务器的主机名（在您的情况下为www.mysite.com）。直接观察IP地址，并且：



您通常在执行未加密的DNS查询之前，
许多HTTPS服务器每个IP地址仅服务一个域，
服务器的证书以纯格式发送，并包含服务器名称（可能在多个服务器之间），
在较新的TLS版本中，有服务器名称指示，客户端通过该指示向服务器指示希望使用哪个主机名，因此，如果服务器有多个证书，则服务器可以提供正确的证书。 （这样做是为了能够远离2。）

，然后发生TLS握手。这包括协商密码套件，然后进行密钥交换。假设您的浏览器和服务器中至少有一个未在接受的套件中包含NONE密码，则密钥交换之后的所有内容都会被加密。

并假设没有成功的代理人中间攻击（即攻击者确实拦截了该连接，并提供了您的浏览器接受的伪造的服务器证书），密钥交换是安全的，并且任何窃听者都无法解密随后在您和服务器之间发送的任何内容，而且攻击者也无法更改内容的任何部分，恕不另行通知。这包括URL和HTTP请求的任何其他部分，以及来自服务器的响应。

当然，以D.W.提到，从加密数据流中可以看到请求的长度（其中包含的可变数据比URL少得多，可能还包含一些Cookies）。这可能会破坏保密性，尤其是在服务器上只有少量不同资源的情况下。还有任何后续资源请求。

但是，URL（或请求的任何其他部分）中的密码仍然应该是安全的-最多可以知道其长度。

评论

而且，服务器名称包含在服务器作为握手的一部分发送回客户端的证书中，并且该证书是“明文”发送的，因此目标服务器名称实际上根本不是秘密的。

–托马斯·波宁（Thomas Pornin）
2011年9月29日13:20在
securityweek.com/hackers-can-intercept-https-urls-proxy-attacks

–汤姆
16年7月29日在14:41
简而言之：如果您访问某个NSFW URL，那么该行中的任何人当时都可以知道您已连接到该站点，但是没人可以知道您所请求的NSFW内容

–usr-local-ΕΨΗΕΛΩΝ
16 Dec 28'在8:56
@everydayjoe感谢您的编辑建议，但我认为这里不需要。它也已经合并到其他答案中。

–PaŭloEbermann
18年7月10日在18:19

#2 楼

您应该假设该URL没有受到保护，也就是说，一个被动的窃听者可能能够了解您正在访问的URL。

我意识到这与其他人所声称的相矛盾，所以我想更好地解释。

域名发送后的所有内容都是加密的。例如，如果url为https://www.example.com/foo/bar.html，则攻击者可以看到www.example.com，而对HTTP请求（GET /foo/bar.html HTTP/1.0）进行了加密。这确实防止了窃听者直接看到URL的路径部分。但是，URL的路径部分的长度对于窃听者可能是可见的。此外，窃听者也可能会看到其他信息（例如，您访问的页面的长度）。这是攻击者的大门。如果攻击者可以窃听您的https流量，已经有一些研究利用此脚步来了解您正在访问的URL。

虽然不能保证这些攻击会成功，但我建议最糟糕的情况是谨慎的做法：假定窃听者可能能够了解您正在访问的URL。因此，您不应该假设SSL / TLS从窃听者隐藏了您正在访问的页面。

是，https确实为您访问的URL提供了完整性。

P.S.另一种警告：在实践中，如果网站未使用HSTS，则sslstrip和其他中间人攻击可能会针对许多或大多数用户成功。这些攻击可能同时侵犯URL的机密性和完整性。因此，如果用户通过不安全的网络（例如开放的Wifi）访问未使用HSTS的网站，则应警惕攻击者可能能够获悉用户正在访问哪些页面。减轻sslstrip威胁的部分缓解措施是，用户可以在所有地方使用HTTPS，站点可以采用HSTS。

#3 楼

正如@PaŭloEbermann和@Jeff Ferland告诉您的那样，GET请求是使用SSL加密的，因此是安全的。但是，请不要忘记，许多Web服务器都记录GET请求和参数，并且您通过GET发送的任何凭据或其他敏感信息都可以写到某处的日志中。因此，提交敏感数据时应使用POST（也将使用SSL加密）。

属于“加密不是解决所有问题的不可思议的安全性”类别。

评论

日志问题是可以的。在我的攻击模型中，攻击者只能拦截流量，而不能侵入服务器。但是，由于您提到的原因，在将来的版本中，我将开始使用POST。

– Jus12
2011-09-30 6:44
@ Jus12这对于抵抗社会攻击（攻击者可以从屏幕上读取URL）也更好。

–PaŭloEbermann
2011-09-30 19:42
请注意，仅使用POST是不够的（它将被记录为相同），还需要确保“秘密”信息位于请求正文中，而不是URL中。

–PaŭloEbermann
18年7月10日在18:21

#4 楼

在您的会话开始之前，以下内容会泄漏：


服务器的IP地址
服务器的证书

其中将包括发布的域名证书上的内容，尽管不能保证它会与您使用的内容相匹配。


您的DNS查询

没有与之无关的数据或请求在SSL会话开始之前，将创建SSL连接（GET ...）的消息发送到服务器。该URL作为页面请求的一部分发送，并与会话中的任何流量一样受到保护。

#5 楼

是和否。

URL已正确加密，因此永远不要直接显示查询参数。

但是，流量分析通常可以获取URL的长度-并且知道服务器和url的长度通常足以窃听正在访问的页面，尤其是在假定单击页面上的链接的情况下。 Google用于“流量分析ssl浏览”或类似的主题（如果您感兴趣）。

在您的用例中，这仅是至关重要的。流量分析的巧妙使用可能会显示用户名的长度和/或密码的长度，这取决于所获取的其他URL是否也包含用户名。如果将用户名/密码填充为固定长度，则可以避免这些攻击，但这可能不值得麻烦。

#6 楼

TLS堆栈开始发送服务器名称指示（SNI，http：//en.wikipedia.org/wiki/Server_Name_Indication； http：//www.ietf.org/rfc/rfc3546.txt）。这是明文发送的，这意味着窃听者可以看到您在地址栏中键入的服务器名称。