一、首先，介绍两个安全机制
(1)HTTP严格传输安全HSTS
HSTS(HTTP Strict Transport Security)[1]，是国际互联网工程组织正在推行的Web安全协议，其作用是强制客户端(如浏览器)使用HTTPS与服务器创建连接，用来抵御SSL剥离攻击。
图1 HSTS原理图
如图所示HSTS运作原理图，对其进行拆解：
1) 用户在浏览器中首次打开使用HSTS机制的网站时，如果使用HTTP协议①，则服务器会返回带有StaticTransport Security(STS)的HTTP头②，并通知浏览器将协议重定向为HTTPS，浏览器重新使用HTTPS协议与服务器进行连接③。
2) 用户浏览器客户端与服务器进行通信，服务器向浏览器发放证书④⑤。网站域名会被添加到浏览器的HSTS列表中，在之后与服务器的通信中强制使用HTTPS协议。当用户再次使用HTTP协议访问目标网站时⑥，会被HSTS机制强制转换为HTTPS协议进行连接建立和信息传输⑦。
HSTS Preload List：HSTS preload list是Chrome浏览器中的HSTS预载入列表，该列表中的域名被硬编码在了浏览器中，当访问列表中的网站时，即便是第一次访问，也会默认使用HTTPS协议，用户网站需要申请和审核才能加入列表。Firefox、Safari、Edge等浏览器均采用这个列表，下面讲述中所使用的列表中的域名当时均不在Preload List中。
(2)内容安全策略CSP
CSP(Content Security Policy)[2]，是一个附加的安全层，可以通过 HTTP 头信息的Content-Security-Policy字段，或者网页的标签进行设置，用来帮助检测和缓解XSS、数据注入等攻击。
图2Github CSP配置信息
内容安全策略通过包含Content-Security-Policy的HTTP头来创建一个白名单制度，规定浏览器只允许加载和执行白名单域中的资源和代码。如果不在白名单域中，即便攻击者发现了漏洞，也无法实施注入攻击。图2为Github的CSP相关配置，配置相关细节见参考[3][4]。
(3)安全&危险
HTTP严格传输安全(HTST)和内容安全策略(CSP)这两个新的功能已经被内置到了Firefox和Chrome浏览器，并且之后很有可能也被其他主流浏览器支持。
一位研究学者将这两个安全机制结合进行利用，即使在用户删除浏览器历史记录的情况下，依然可以对用户浏览器访问过的域名进行获取，所获取的用户的访问历史列表可以用来追踪数百万的互联网用户。
是不是感觉本来用来保障用户安全的机制被“策反”了，成了对自己实施追踪的工具?下面我们将具体讲述，“策反”工作是如何执行的。
二、“策反”工作
Yan Zhu，一个独立的安全研究学者，在圣地亚哥的2015年Toorcon的安全会议上示范了自己开发的Sniffly追踪网站，Sniffly中内置了一个从Alexa网站上获取使用HSTS，并且不在HSTS Preload List中的域名，利用HSTS和CSP机制对用户浏览器访问过的域名进行嗅探。
如下图，访问http://zyan.scripts.mit.edu/sniffly/，页面中会显示用户已访问过和未曾访问过的域名列表。如图3为在Firefox上测试的结果，GitHub上已经有POC代码https://github.com/diracdeltas/sniffly/tree/master，目前Chrome48以上版本已经修复该漏洞。
图3Firefox对Sniffly测试的结果
Sniffly的工作原理(以bitcoin.org为例)
Sniffly使用形式设置CSP，而Firefox浏览器不支持这种方式，因此将对Chrome浏览器和Firefox浏览器上不同的工作原理分别进行讲述。
(一) Chrome浏览器
(1) 首次访问使用HSTS的情况
当用户第一次使用HTTP协议访问bitcoin.org时，服务器返回包含STS和CSP的HTTP头，通知浏览器使用HTTPS协议访问网站，并且只执行CSP规定域中的资源。图4展示了HTTP重定向到HTTPS的耗时情况。
图4HTTP连接重定向耗时
(2) 曾访问过HSTS目标网站的情况
当用户已经访问过使用HSTS的目标网站时，即bitcoin.org已经被添加到了浏览器的HSTS列表中。如图5和6显示了用户第二次访问使用HSTS的网站，以及HSTS强制浏览器内部重定向为HTTPS协议与服务器进行交互的情况。
图5第二次访问使用HSTS网站
图6浏览器强制使用HTTPS协议
(3) CSP阻断HTTPS的重定向(Chrome浏览器)
Sniffly利用CSP的白名单策略，对资源的加载进行限制。Sniffly作为第一方网站，通过对使用了HSTS的网站(这里称作“第三方网站”)构建img请求(即加载第三方的img资源)，实施CSP的阻断，Sniffly在Chrome浏览器的工作原理，如下图所示。
图7CSP截获HTTPS重定向过程
如图7所示CSP截获HTTPS的重定向过程，对其进行拆解：
1)CSP部署：用户打开Sniffly网站，通过网页的设置CSP为“img-srchttp”jk，即限制浏览器只可以加载使用HTTP协议的img资源。针对使用了HSTS机制的域名，构建img请求lo，图中为的情景1和2标识用户是否访问过目标网站(img的src随机生成，是为了屏蔽浏览器缓存的影响)，如图8所示。
图8 Sniffly的CSP部署和随机img src 地址
2)未访问过目标网站：若用户浏览器未访问过bitcoin.org，则首先会进行HTTPS重定向m，更换HTTPS协议再次发起请求n，HTTPS协议的img请求会被Sniffly的CSP阻断(如图9)。
3)曾访问过目标网站：若用户浏览器曾访问过bitcoin.org，由于使用了HSTS机制，HTTP请求在浏览器内被强制转换为HTTPS协议p，HTTPS协议的img请求会被Sniffly的CSP阻断，如图9所示。
图9 Sniffly对HTTP协议进行阻断
注：使用CSP阻断HTTPS不只为了获取重定向的时间，如果CSP未对HTTPS的重定向连接进行阻断，则成功连接后的HSTS机制会污染用户的访问历史，因此造成误判。
(二) Firefox浏览器
由于Firefox浏览器不支持通过的形式设置CSP，因此Sniffly利用了浏览器的漏洞Issue436451[8]对Firefox历史列表进行嗅探，该漏洞同样利用HSTS机制，如图10所示(图中隐去了PreloadList部分)。
图10 Issue436451漏洞原理示意图
利用该原理构造类似http://example.com:443/favicon.ico 的请求，浏览器对曾经访问过的目标网站使用HTTPS协议与服务器连接，而未访问过的域名，则无法正常建立连接，因此这种方式不会污染浏览器的HSTS列表，如图11所示使用fidder抓包的效果。
图11 Firefox中构造的img请求示意图
(三) 结果判定
由图4和图5可以得出，通过服务器301/302进行的HTTPS重定向耗时在100毫秒以上，而浏览器内部重定向(Internal Redirect)几乎不耗时。通过CSP对HTTPS进行阻断，利用JS中img的onerror事件进行监听，只获取重定向消耗的时间，通过计算时间的消耗对用户是否访问使用HSTS的网站进行判定。
不同用户的浏览记录千差万别，以浏览器历史信息作为用户的追踪依据，能够保证用户的唯一性，并且Sniffly中的列表只是使用Alexa网站中网站列表的很小一部分。
不同浏览器中的HSTS位置
Firefox的HSTS列表：打开Firefox的文件浏览，在地址栏中输入%APPDATA%\Mozilla\Firefox\Profiles\，双击其中的目录，在文件夹中找到SiteSecurityServiceState.txt，其中包含着HSTS的列表。
图12Firefox中的HSTS列表
Chrome的HSTS列表：在Chrome浏览器中，打开chrome://net-internals/#hsts，可以在其中查询、增加、删除本地HSTS相关的域名信息。
图13Chrome中的HSTS列表
(四) 第二代追踪Sniffly2
以上的技术实现均为第一代的Sniffly，Yan已经实现了第二代的Sniffly2。Sniffly2主要针对基于Chromium引擎的浏览器，使用HSTS的header和Performance Timing API嗅探浏览器的历史记录，同样是使用时间差机制对用户是否访问过目标网站进行判断。
Github代码：https://github.com/diracdeltas/sniffly
测试网站：http://diracdeltas.github.io/sniffly/
三、最后
目前这种追踪方式，仅仅能够追踪到使用HSTS保护的网络站点，并且只对域名和子域名进行了记录。如果用户的浏览器装有HTTPS Everywhere[11]插件(强制所有支持HTTPS的站点使用安全连接)，这种追踪方式也是没有效果的，不过，这个缺点在之后应该通过修改代码就能够解决。
| 
