一、首先，介紹兩個安全機制
(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的站點使用安全連接)，這種追蹤方式也是沒有效果的，不過，這個缺點在之后應該通過修改代碼就能夠解決。
| 
