例如，假设以下是通过一个IP在5分钟内指向两个网站的HTTPS URL：
“ A.com/1”、“A.com/2”、“A.com/3”、“B”。 com / 1“，” B.com/2“。

对数据包的监视将显示：


没有任何内容，
仅显示IP具有访问“ A.com”和“ B.com”（仅表示DNS），
仅显示IP访问过“ A.com/1”和“ B.com/1”（第一个HTTPS请求每个站点），
显示访问过的所有HTTPS URL的完整列表，
只显示“ A.com”和“ B.com”的IP，
还是其他？

相关问题：
我的公司可以看到我去过的HTTPS站点吗？专门解决“仅公开IP访问过“ A.com/1”和“ B.com/1”（每个站点的第一个HTTPS请求）”的情况-尽管对此的错误可能性很高，并且很高兴删除重复的问题。


注意：这是后续任务答案发布为：为什么HTTPS不是默认协议？

#1 楼

TLS向窃听者揭示以下信息：


您正在联系的网站
URL其余部分的长度（可能是近似值）
（可能）您访问的页面的HTML的长度（假定未缓存）
您访问的页面上的其他资源（可能是近似）的其他资源（例如图像，iframe，CSS样式表等） （假设未缓存它们）
发送每个数据包和启动每个连接的时间。 （@nealmcb指出，窃听者在计时方面学到了很多东西：每个连接的确切启动时间，连接的持续时间，每个数据包的发送时间和响应的发送时间，服务器响应的时间每个数据包等）。

如果您通过单击一系列链接与网站进行交互，则窃听者可以在网页上的每次单击中看到其中的每个。可以结合使用此信息来尝试推断您正在访问的页面。在所有情况下都是相同的长度。但是，您的示例选择得很差：它不能代表网络上的典型做法。通常，特定站点上的URL长度会有所不同，因此会显示有关您正在访问的URL的信息。此外，页面的长度和资源的数量也各不相同，这揭示了更多的信息。因此，您不应假定TLS隐藏了您正在从窃听者访问的页面。 （我意识到这是违反直觉的。）


添加：以下是一些有关HTTPS流量分析的文献研究的引文：陈硕，王瑞，王小峰，张可欢。 Web应用程序中的侧通道泄漏：今天的现实，明天的挑战，IEEE安全性和隐私权2010。例如，它显示了基于AJAX的搜索建议如何甚至可以通过SSL揭示您正在键入的字符。这是本文的高级概述。
张克K，周立，王瑞，王晓峰，陈硕。 Sidebuster：Web应用程序开发中的边通道泄漏的自动检测和量化。 CCS2010。
Marc Liberatore，Brian Neil Levine。推断加密的HTTPS连接的来源。 CCS2006。
乔治·丹内斯（George Danezis）。 HTTP协议基于TLS的流量分析，未发布。加密的HTTPS流中的隐私漏洞。 PET，2005年。
孙启祥，Daniel R. Simon，王一民，Wilf Russell，Venkata N. Padmanabhan，邱丽丽。加密的Web浏览流量的统计标识。 IEEE安全与隐私2002。
Andrew Hintz。使用流量分析对网站进行指纹识别。 PET2002。
郑海宁，罗恩·阿夫努尔。 SSL加密Web浏览的流量分析。班级项目，1998年。
Shailen Mistry，Bhaskaran Raman。量化加密Web浏览的流量分析。班级项目，1998年。


评论

+1 @ D.W .：选择您的信息作为答案。对我来说，如果您概括提出的威胁，对基于AJAX的HTTPS事务进行n-gram攻击就不足为奇了，尽管他们同意这清楚地表明了在某些情况下问题的严重性。感谢您发布链接，我认为这确实提高了回答的质量。干杯!

–错误
2011年6月8日，下午3:22
很棒的答案！我认为您应该包括以下事实：攻击者对时间了解很多：连接的确切时间，连接的持续时间，每个数据包来回的时间，服务器响应每个数据包的时间等。一方面，但正如我假设参考文献详细解释的那样，也可以通过许多方式来获取信息。

–nealmcb
2011年6月8日下午5:00
@ D.W。 4年后，HTTPS是否仍会泄漏这些长度信息？

–user2203703
15年11月7日在18:35
@ user2203703，是的。

– D.W.
2015年11月8日，下午3:17
@niico，正确，查询字符串是加密的，不能直接查看（但是其他可以，如果窃听者可以基于其他内容推断出有关查询字符串的信息，那将同样糟糕）。

– D.W.
17年2月1日在17:49


#2 楼

第二选择。通常，

当浏览器访问HTTPS网站时，它将建立TLS隧道，该隧道涉及不对称的密钥交换（客户端和服务器就共享机密达成协议）。该密钥交换机制使用服务器公共密钥，服务器将其显示为证书的一部分。服务器证书包含服务器名称（例如A.com），并且客户端验证名称是否与期望的名称匹配（即URL中的服务器名称）。服务器证书是在密钥交换之前致命地发送的，因此是纯视图。派对。给定的隧道可以重用于其他几个HTTP请求，但是（通过构造）它们都用于同一服务器（相同的域名）。

评论

证书必须包含主题名称（在CN或SAN中，如果适用），该主题名称要么是URL的主机名，要么是与主机名匹配的通配符，但是只有最左边/最低的DNS标签可以是通配符，因此，如果不是实际的主机名，至少在层次上接近它。

–dave_thompson_085
18年1月14日在2:48

#3 楼

这实际上是一个模糊的问题。这就是为什么。当您访问https服务器时，http（在此处证明https只是基于TLS的http）比它下面运行的TLS更高。首先要做的是协商TLS设置，例如密码套件，密钥，握手等。这是在https端口上完成的，但是尚无http数据。然后，客户端或服务器将转换为加密模式，在此模式下，所有内容均被加密。

协商完成后，它转换为只是普通的旧http协议的应用程序数据作为有效负载。

但是此数据已加密，因此没有显示URL。但是，众所周知，服务器和客户端的IP地址未加密，因为它不是在TLS层中使用，而是在TLS以下的IP层（较低级别）中使用。 TLS是IP数据包的有效负载，其中包含IP地址，端口号，诸如tcp之类的IP协议等作为标头。因此，因为仅对TLS进行了加密，所以不会对这些项目进行加密。

此外，只要服务器和/或客户端的证书可以“链接”到根权限或具有有效的证书，窃听就不是问题。

最后我想说TLS和HTTPS实际上是一个基于客户端和服务器首选项以及最少支持的框架来协商最高安全级别的框架和算法。基本上，TLS不会定义使用的实际加密。这些是密​​码套件，通常在与TLS协议不同的单独RFC类型设置中进行管理。因此，仅基于HTTPS，仅说HTTPS提供的区域的安全质量还不够。只能假设一些最低的安全性和难度。密码套件的实际质量是一个复杂的问题，并且对于每种密码套件都是特定的，因为其中有许多依赖完全不同的机制。

编辑
还引起我注意的是，TLS的服务器名称指示符（用于共享IP地址的多个服务器）扩展确实可以告诉任何人所访问服务器的域名。仅在发送到服务器的第一条消息中，一个字段将包含域名的ASCII文本，例如“ google.com”。因此，监视第一个数据包的任何人都可以轻松看到此信息。这是当今许多网站主机中常见的选择。但是任何URL都不应该是不安全的。

最后，这实际上取决于密码套件，它们并不完全相同，就像没有加密的默认密码套件一样。如果将您的浏览器和网站配置为支持这些功能，那么任何人都将看到纯http。因此，取决于您的Web浏览器和服务器，从IP地址到IP地址以及域名（带SNI扩展名的TLS有时也可以通过其他方式解决这不太容易）的任何地方，在某些其他情况下，一切取决于密码套件的优势。