服务器名称指示(SNI) [ 18)是一个扩展的TLS协议,指定主机名(例如,网站)浏览器或任何其他客户想连接。添加此扩展的TLS握手(更确切地说在ClientHello记录)使目标web服务器能够处理多个网站(因此证书)在同一IP地址和只提供证书,通过SNI客户机请求。由于IPv4地址空间的稀缺和世界范围内部分对IPv6协议的支持,更有利于服务器提供者使用SNI作为一个潜在的解决方案,因此,限制IPv4地址已经购买的数量和维护。此外,它也不是不寻常的共享主机提供商分配一个IP地址的所有或大部分的客户网站,从而共享同一TLS证书与发布商(通常情况下 19]。因此,SNI今天现代web上的广泛支持的扩展。

作为初始RFC(草案 18这个扩展的已经出版于2003年,所有现代客户支持SNI通过发送请求的网站的域的握手。尽管TLS≤1.2提供了加密(TLS 1.3 ServerHello加密记录后,所以SNI仍以明文发送),但最后的握手,因此发送SNI明文。因此,任何中间人(MitM)能够提取明文从网络流量域名,反过来,是用于广泛的工业和学术著作,我们将展示部分 3.1。

因为隐私倡导者发现SNI扩展消费者隐私的问题,一个新的扩展名为“ESNI”[ 20.)是在2018年推出,加密对称密钥来自原始SNI,例如,以前的DNS通信。更具体地说,客户端请求的ESNI记录给定域名从ESNI-enabled DNS解析器。diffie - hellman交换然后得到一个对称密钥设置DNS解析器,它可以用于加密原始SNI和ClientHello的一部分发送。还包含了一个散列的ESNI扩展关系的公共keyshare ClientHello扩展本身。为此,ESNI不能使用另一个ClientHello,防止一个MitM重现同样的用自己的ClientHello ESNI。显然,DNS解析器和web服务器必须支持ESNI SNI避免潜在的回退标准。然而,额外的需求完全遵守ESNI保证保护域名:(i) TLS 1.3加密ServerCertificate记录设计选择在TLS 1.2中没有实现。这是重要ESNI表明证书发送,这意味着一个明文的证书可能间接泄露域名。(2)ESNI记录必须要求通过身份验证和加密通道(例如,DNS / HTTPS)客户机和DNS解析器之间,防止MitM提取记录。截至2020年6月,Firefox和Chrome已经实现ESNI等几个组织Cloudflare和谷歌也有ESNI-enabled DNS解析器可被公众使用( 21, 22]。注意,最近更新ESNI(草案 20.]介绍了一些技术变化相关加密ClientHello记录和也更名为ESNI完成 回声( 23]。

最后,哎 24)是一种协议,它允许客户端安全通信DNS请求和响应在HTTPS使用一个中间DNS解析器。明文DNS /端口53相比,该协议通常运行在端口443和加密所有DNS沟通。2019年6月以来,卫生署一直支持Mozilla Firefox和Chrome。尽管哎明文DNS解决一些固有的问题,意见有分歧集中所有DNS通信是否默认一个中间解析器将提高整个终端消费者的隐私 25]。

在客户端可以与web服务器/ HTTPS, TLS握手必须首先被执行。在握手,ServerCertificate记录通常为客户端提供了一个x公钥证书( 26证明了web服务器的身份。选择哪一种证书提供客户端通常是要么基于客户请求的IP地址是或SNI小节中提到的 2.1。中包含的身份的名字 普通的名字的证书,客户来验证它是否匹配的域名网站,它想访问。然而,以防多个域名,颁发的证书 普通的名字字段不能适应所有领域,从而证明中的一个额外字段名为主题选择的名字(SAN)介绍。该字段包含所有的域名证书控件,使多个网站背后的一个IP地址更容易管理。

此外,圣领域甚至是必要的为老客户,不支持SNI因为他们并没有提供一个方法来显示域名在TLS握手。non-SNI支持客户端就能够自由地选择域名要访问的san。虽然SNI扩展被广泛支持的所有现代浏览器(例外:例如,IE 6.0 pre-Windows Vista和Android 1. x - 2. x),通常可以作为non-SNI客户端,因此接收SANs的列表,这表明一些或所有域名的IP地址或底层web服务器可以处理。之前的工作执行存在这样的提取( 27),但尚未探索的零利率上下文。

在HTTPS通信时,url和HTTP的身体数据等敏感数据加密,从而防止敌对mitm。然而,元数据通常不被认为是敏感的时机和规模HTTP数据包在TLS记录仍可测的对手。通过利用正是这样的元数据的特点,MitM能够区分不同的网页或网站,因为它可以观察模式在客户机和服务器之间的通信。这些模式的检测奠定了基础的网页或网站指纹(WPF)。程和Avnur 28)是第一个考虑的可能性,指纹识别网页/ HTTPS。在过去的十年里,相当数量的作品建立在这个最初的概念,设计了新的技术来进一步提高实用性和准确性( 29日- - - - - - 31日]。一个广泛的概述WPF攻击/ HTTPS提出了以前的工作,因此本文的范围。

相反,我们讨论了一般考虑需要理解的概念应用于我们的论文。深入研究这些问题提出了相关的华雷斯et al。 16]。首先,(我)之前的工作主要是集中在指纹识别每个网站的主页,而不是收集多个网页/网站。因此,这样一个WPF分类器是无法准确预测其他网页中包含相同的网站。此外,(ii)网页的集合指纹之前必须建立能够预测特定网页被访问。例如,如果敌人感兴趣预测所有网页从维基百科,它首先必须multisample在维基百科上每一个网页为了构建必要的指纹,在大多数情况下这是一个不切实际的任务。最后,(iii)的各种现代客户很重要,导致网络流量的不同从而导致WPF攻击大幅减少在精度上执行客户(例如,浏览器)没见过。

此外,这些研究的目的通常不是提供零利率的功能,而是揭示的可能性绕过某些协议或Tor或vpn等对策。因此,现实的WPF已知模型的精度远低于零缺陷是可以接受的。事实上,零利率,显然,识别给定的网站或网页应该有极低的假阴性,防止问题的消费者使用零利率的网站,同时还被指控在他们的数据计划由于潜在的错误分类。

虽然网站专门为零利率识别方法研究在学术文献中,没有多少研究了零利率的实际实现由isp和CPs [ 1, 9]。许多专利,将零利率已由DPI供应商,isp, CPs如Facebook ( 37],t - mobile [ 38)和思科( 39]。尽管重大金融努力投入这些技术,我们不过展示他们有相同的技术局限和漏洞,我们观察在学术文献。这些限制之一是无法自动检测或阻止搭便车的攻击,攻击者可以修改自己的网络流量,这样它就像一个不加增值税服务或网站。另一个担忧是,大多数当前的方法是不可持续的在不久的将来,因为他们不支持新崛起的加密协议,我们认为最终会消除许多现有的方法。

在本节中,我们详细讨论这些网站识别方法和分析是否适合检测交通不加增值税。此外,我们探讨实际问题和搭便车行为攻击的可能性,最后,研究这些方法的长期性能。为了更好地解释这些方法,流的平均消费者浏览网页如图 1我们将在本节中引用这个数字。总结现有的网站提供了识别方法表 1这个表和列的解释如下: (我)

HTTPS:该方法能操作与HTTP / TLS流量。

我们的方法“Open-Knock”也列在表和讨论部分 4。 (1)

非- - - - - - HTTPS。确定网站非http流量很容易实现,因为它是未加密的。Kakhki et al。 9]表明,t - mobile等一些isp解析HTTP头信息以识别网站。例如,提取“主机”头可能表明所使用的网站,而“内容类型”头指定类型的网络流量。通过解析这些每个HTTP请求和响应头,ISP能够准确零利率特定类型的流量从一个特定的网站。然而,作为一个客户端可以修改这些头,绕过这个方法很简单。截至2020年6月,排名前100万的网站的85%和85%的互联网页面加载默认使用HTTPS ( 44, 45),从而使其无法解析明文的HTTP头信息,大多数的这些网站。

说明我们的方法的细节之前,我们首先制定一个实际的场景,在该场景中,我们的方法是利用。我们的环境由图中相同的政党 1。ISP,目前作为MitM,想确定不加增值税的消费者使用一个网站,这样可以正确地应用相应的零利率政策。为了预测网站的域名,ISP可以提取的IP地址的所有TCP连接消费者的网络流量。通过提供这些IP地址我们的方法,输出一个结果列表,匹配每个IP地址与网站的域名访问的特定的消费者。

因此,我们提出我们的新方法的细节确定HTTPS网站零利率,称为“Open-Knock。“在这里,一个HTTPS网站的域名是确定基于最初的IP地址 我,从网络跟踪。此外,我们的过程也由一个(可选的)步骤,适用于网页指纹,完整的元数据 T从所有TCP连接的IP地址 我是必需的。Open-Knock的部署,使得我们能够逃避主义的一些保护特性ESNI并能延长之前作品的实用性的提取是基于明文域名DNS和SNI等。提出了一种Open-Knock的总结如下: (1)

提取从san和执行反向DNS域名,IP地址 我

每一个时间步的过程是由一个分段表示。输出每一步的域名列表是下一步的输入列表,其中每个输出列表 R。在过程的结束,名单 R将包含匹配的域名可能最初的IP地址 我和网络跟踪(可选) T。给定一个IP地址 我,Open-Knock可以产生一个预测相对较高的确定性或产生任何预测。在零利率的情况下,我们认为,生产没有预测远比生产低确定性的预测作为一个ISP通常已经有大量可用的网络流量,因此,更准确、定性输出数据定量输出数据申请其零利率政策。

我们建立了一个DPI-like MitM监测交通流从客户机到目标web服务器。为每个目标TCP连接,客户端在端口443上启动一个未知的IP地址,IP地址 我保存DPI和用作输入元素来确定相应的域名。

这个过程的第一步开始当一个新的IP地址保存。这里,MitM启动4新带外TCP连接的IP地址在端口443和1.1执行TLS握手。这个握手发起以下4个选项: (1)

执行一个TLS握手与有效的参数和一个有效的SNI扩展,是任何现代浏览器实现。

取决于背后的服务器实现IP地址,每个单独的选项可能会返回不同的域名SANs的TLS服务器证书记录。我们的分析表明,选择1和4组合将返回大约96%的域名。所有提取圣域名选择的选项是收集并作为初始输入列表 R下一步的流程。除了域名从无聚集,我们还通过IP的反向DNS请求PTR记录 我并将接收到的域名添加到初始输入列表 R。减少搭便车攻击的风险,需要部署一个额外步骤来阻止可能的危害web服务器诡诈的像拥有一个特定的域名。这一步由验证是否收到受信任的CA签署的证书和目标服务器是否已经获得证书的私钥。为了这样做,TCP带外连接完成TLS握手为每个域和验证证书的正确性。

与输入列表 R递归域名,我们要求每一个根域名的记录(例如,域名“help.example.com”将导致根域“example.com”)通过DNS。检查每个返回的记录和相应的域名 R随后从列表中移除,i.f.f.记录为空,这样我们过滤掉所有域名无法访问外部。接下来,从这些剩下的通过记录的IP地址,我们把第一个IP的每个域和执行一个HTTPS请求在端口443上的SNI将域名。如果请求失败或如果它不返回一个状态码200年至400年,然后我们也删除完整的记录和相应的域名从列表中 R。为此,所有域名都不可能达到通过这个IP地址被删除。最后,可能HTTP重定向捕获从剩下的域名和原始列表中的域名将被取代的根域名重定向。

在这一步的过程中,剩余背后的HTTPS网站的域名可能含有其他网站的链接不同的域 Y,但背后的服务器的IP地址 我也能提供证书吗 Y。例如,溢价的主页共享托管提供商通常包含url的网站为客户开发的,其中的一些客户网站接受SNI值的其他客户网站由于共享背后的证书或CDN-type服务器托管提供商的IP地址。利用这些信息,每个剩余网站的主页 R爬,直接捕获url指向其他域名。捕获的url然后再次访问通过最初的IP地址 我通过执行一个完整的HTTPS请求与SNI将域名从捕获的URL,以确认是否可以和一个有效的证书是可用的。可获得该域名,如果相应的HTTPS请求不失败,收到HTTP状态代码是在200年和400年之间。根域名的访问url提取并添加到列表中 R。

例如,我们从一个托管提供商拥有网站开始 一个和 B,但只有 一个是在 R。通过网站的主页爬行 一个返回域名 B和 C。对于这两个域,我们发起一个TCP连接IP 我,设置SNI ClientHello到对应的域名的网站( 一个和 B),最后请求根网页的网站。只有域名的请求将被添加到成功 R。

尽管目标在一个共享web服务器可以提供大量的无证书或它选择一个基于IP地址,它并不意味着所有这些域名的DNS请求导致相同的IP地址。例如,域 X和域 Y共享相同的证书提供的IP地址的TLS握手 我,而DNS记录请求域 X和域 Y可能都返回一组不同的IP地址,无论地址吗 我包括在内。在一般情况下,我们观察到有两个场景中,这种行为可能发生:(i) DNS负载均衡分布目标web服务器的工作负载转移的循环或参数化的方式返回的IP地址。(2)预先分配的IP地址来确定域名,因此DNS解析器简单地返回一个主要为每个域组固定的IP地址,无论如何构建相应的TLS证书。

场景(i)的目的是很难预测的“平衡”等参数可能取决于服务器的计算能力或位置。然而,场景(ii),相反,相对可预测的结果。检查如果CP (ii)实现了场景,我们执行以下步骤为每个域名 d在 R: (我)

首先,我们发出一个递归的DNS请求域 d并保存响应的IP地址 P₀( d)

现在,我们考虑CP的IP地址 预先分配i.f.f.超过一半的域 匹配,小矛盾在返回的IP地址是可能的。例如,CP可能执行额外的负载平衡通过移除IP地址从DNS记录当时无法访问或通过只显示一个随机子集的IP地址分配给域名。在CP IPs是预先分配的实例,我们将删除每一个匹配的域 d从 Ri.f.f IP地址。 我不包括在 P₀( d)或 P _问( d)。如果不预先分配IP地址,我们继续用同样的列表 R是由前一步。

到目前为止,列表 R可能任何一个域名左(或多个域名的根名称相同)与不同的根名称或多个域名。在前一种情况中,Open-Knock将预测的域名 R这个过程结束。在后一种情况下,我们不能进一步降低列表,因此,无法预测一个域名。然而,指纹识别其余域名做出最后的预测可能是有的,但可能不会达到预期的精度被部署在零利率的环境。例如,如果对应的域名的网站包含很多页,很难指纹的网页数量的权利。然而,我们将讨论所有剩余的指纹识别过程域零利率政策这样的指纹识别方法是理想的。

在这个指纹识别过程中,我们认为每个域是一个功能的网站,现在就需要一个流量跟踪 T(只包含TCP连接与IP 我)网站的客户端访问期间的问题。加强这种附加信息,我们将指纹其余网站实时列车现有WPF模型,最后,应用我们的交通痕迹 T该模型以产生一个最终的预测。首先,我们必须捕获每个网站的固体视图构建一个精确的指纹。在工作之前,每个网站的主页的通常被认为是给一个完整的视图website-an假设是不准确的 15]。因此,我们的方法捕获多个网页在多个浏览器为了创建一个更健壮的指纹,在实际的工作环境。创建我们的列表为每个网站网页,我们第一次爬行网站的主页与一个固定的爬行深度和保存每个URL链接到相同的域 d和HTML内容类型” 文本\ html”许多 h随机的url然后选择。如果少于 hurl是可用的,然后选择所有url。选择一个大 h将生成一个更健壮的网站上的指纹,但增加网络带宽和训练时间。url的列表后,我们样品每个网页进行下面的流程与两个不同的浏览器: (1)

我们通过浏览器访问每个选择URL使用硒( https://www.seleniumhq.org/),捕获所有TCP连接启动IP地址 我

在我们的研究中,我们使用最新的桌面版本(2020年6月以来)的Firefox和Chrome浏览器。因此,总的来说,2 h为每个网站捕获样本。所有样品在这个过程被认为是捕获 训练数据为我们的WPF模型。此外,我们输入训练数据到WPF模型提出的Liberatore和莱文 56)和规范化等提出的( 57]。这个模型使用朴素贝叶斯分类器,每个类代表一个网站。最后,我们的网络跟踪过程 T类似于我们所做的与我们的训练数据和提供加工样品 TWPF模型并使用它的输出类作为我们的最终预测。虽然我们可以选择任何WPF模型这一步,我们的初步观察表明,该模型不需要大量样本的准确识别一个网站通常就是这样与最近的模型( 58, 59),和当前使用的模型是专门设计了培训只在TLS记录大小的特性,这样的模式基于时间差异是消除。

我们进行一个实验Tranco排名前6000的网站列表,我们将我们的Open-Knock方法应用到一个IP地址对应于每个Tranco网站。为了做到这一点,我们首先执行一个DNS请求每个网站(域名)Tranco列表并使用第一个响应中的IP地址作为我们的初始输入方法。类似于之前的工作,所有的网站列表中,没有根路径上首页,有无效的TLS证书,没有在欧洲(non-GDPR兼容的网站经常拒绝访问欧洲消费者),或负载超过20秒,从列表中被删除,导致3474年的网站。例子是网站不支持HTTPS web请求或那些阻止我们重复某种类型的防火墙。尽管规避这些问题是可能的,我们没有试图这么做因为伦理问题。我们每个IP域进行分类预测 正确的, 不正确的,或 未知的。我们的结果显示在数据的划分 2和 3。在这个图表中,我们观察到50.5%的网站可以发现仅仅基于IP地址。此外,9.2%的IP地址,一个不正确的预测是,往往由于网络提供者(例如,WordPress)。事实上,这些提供者只支持SNI-capable浏览器,因此没有SNI的所有请求重定向到的默认主页提供商。这样的问题的另一个例子是,一些网站有多个证书部分无相同,这也会在不同的ip负载均衡,使我们的方法很难作出准确的预测。剩余的40.3%的网站( 未知的预测),我们的方法不可能最终决定选择哪一个域名,因此,产生任何预测。Open-Knock不能产生一个预测的原因在这些情况下解释如下: (我)

空无(19.4%)。当提取SANs的域名(部分 4.2),没有域名返回。这些网站可能不支持non-SNI浏览器能力。因此,可以执行任何进一步措施。

有趣的是,只有3.4%的IP地址在前6000名返回PTR记录等于对应的域名,而1.9% ( 35]。对所有的 未知的有两个或多个域名的预测 R(11.0%),我们申请一个网站指纹识别方法(部分 4.6)在每个相应的网站域名。然而,请注意,可以正确的域名是不正确地过滤掉 R另一个步骤的过程,也就是说,WPF模型(即可能永远不会生成正确的预测。,网站是fingerprintable i.f。f的结果列表 R不是空的,不管中包含正确的域名是吗 R)。虽然WPF模型的相对精度64.2%的错误率35.8%,也就是说,假设正确的域名总是包含在 R,WPF模型应用到我们的实际数据结果的准确性为55.4%。为参数 h截面 4.6,我们已经将这个变量设置为6,导致共12样本网站每个浏览器(2)。

最后,结合IP地址 我和车辆跟踪 T将导致正确的和不正确的预测,分别为56.6%(包括我们的WPF模型的结果)和网站的9.6%,表现优于以前的先进的工作( 35]。然而,一定要注意,推断从单个IP(单个域 35)是基于预处理的数据集网站Alexa前1米,而我们的实验不需要这样的设置和执行方法直接在相应的IP地址。相比之下,猜测域名随机从所有无将导致一个正确的预测19.4%的网站。最后,图 3也显示了列出的所有类型的线性增加,这意味着Open-Knock不受影响的排名(0 - 6000)域名。

一个有效的考虑我们的实验后,我们立即开始识别过程获得的IP地址DNS的回应。然而,ISP可能只处理这么多数据在任何给定的时间,并可能因此提取IP地址和运行流程过了一段时间已经过去了。证明我们的方法仍将实现可接受的结果在这种情况下,我们重新运行试验相同的IP地址(没有WPF模型),但经过一段时间的14天。这里,正确预测的数量只有稍微从50.5%下降到47.9%,而错误的预测仍几乎相等的数字(9.2%到9.1%)。IP地址,返回一个空圣的数量(从29.3%到31.8%)下降的主要原因是正确的预测。我们得出结论,14天的时间对结果的影响较小。比较这些结果和以前的工作的 35)是很困难的,因为他们的数据集生成2小时内,不公开。因此不清楚的数据集 35)成立后14天,IP DNS负载平衡器的旋转是常见的。

我们实验的数据集和一个在线演示工具Open-Knock供公众使用。