everywhere

HTTPS Everywhere 改變更新 Ruleset 機制，變成定時更新...

HTTPS Everywhere 是我很喜歡的一個套件，裡面有 Ruleset，會將 Ruleset 表內認定有支援 HTTPS 網站的 HTTP request 都改成 HTTPS，這可以降低被攔截的風險。像是網站雖然有 HSTS 但第一次連線時走 HTTP 的情況，以及網站本身有支援 HTTPS 但沒有設定 HSTS 時，在網址列上誤打 HTTP 版本的情況。

先前版本的 Ruleset 是隨著軟體更新時，包在軟體內一起更新。這樣的缺點是更新速度比較慢，但好處是不需要伺服器端，而且隱私性也比較高。而現在 EFF 決定還是要推出線上更新的版本，以加速 Ruleset 更新的速度：「HTTPS Everywhere Introduces New Feature: Continual Ruleset Updates」。

We've modified the extension to periodically check in with EFF to see if a new list is available.

而頻寬的部份由 Fastly 贊助：

If you haven't already, please install and contribute to HTTPS Everywhere, and consider donating to EFF to support our work!

如果對這點有疑慮的，也還是可以關掉 auto updater 避免洩漏資訊給 EFF 或是 Fastly。

CloudFlare 把 HTTPS Everywhere 的清單拿到 CDN 上用所推出的產品...

這個產品就如同標題所說的方式而已，做起來不難，只是一直沒人做就是了：「How we brought HTTPS Everywhere to the cloud (part 1)」。

傳統的作法是直接硬幹下去換掉，或是用 header 讓瀏覽器主動轉過去：

A naive way to do this would be to just rewrite http:// links to https:// or let browsers do that with Upgrade-Insecure-Requests directive.

但這有必須有兩個假設成立才可以：

Each single HTTP sub-resource is also available via HTTPS.
It's available at the exact same domain and path after protocol upgrade (more often than you might think that's not the case).

而 HTTPS Everywhere 則是用人力確認了哪些網站可以這樣玩。CloudFlare 利用這份清單改寫程式碼裡面的 HTTP 連結，僅可能將 HTTP 資源換成 HTTPS。算是還不錯的方式...

之後有可能再推出對 HTTP images 與 HTTP assets 的 proxy cache？

Google 的 www.google.com 要上 HSTS 了

Google 宣佈 www.google.com 要上 HSTS 了：「Bringing HSTS to www.google.com」。

雖然都已經使用 EFF 的 HTTPS Everywhere 在跑確保 HTTPS，但這個進展還是很重要，可以讓一般使用者受到保護...

Google 的切換計畫是會逐步增加 HSTS 的 max-age，確保中間出問題時造成的衝擊。一開始只會設一天，然後會逐步增加，最後增加到一年：

In the immediate term, we’re focused on increasing the duration that the header is active (‘max-age’). We've initially set the header’s max-age to one day; the short duration helps mitigate the risk of any potential problems with this roll-out. By increasing the max-age, however, we reduce the likelihood that an initial request to www.google.com happens over HTTP. Over the next few months, we will ramp up the max-age of the header to at least one year.

利用 HSTS 資訊得知網站紀錄的 sniffly

看到「sniffly」這個工具，可以利用 HSTS 資訊檢測逛過哪些網站，程式碼在「diracdeltas/sniffly」這邊可以找到：

Sniffly is an attack that abuses HTTP Strict Transport Security and Content Security Policy to allow arbitrary websites to sniff a user's browsing history. It has been tested in Firefox and Chrome.

測試網站則可以在這邊看到，作者拿 Alexa 上的資料網站來掃，所以熱門網站應該都會被放進去...

主要是利用 HSTS + CSP policy 的 timing attack (有逛過網站而瀏覽器裡有 HSTS 時的 redirect 會比較快，沒有逛過的時候會因為有網路連線而比較慢)：

Sniffly sets a CSP policy that restricts images to HTTP, so image sources are blocked before they are redirected to HTTPS. This is crucial! If the browser completes a request to the HTTPS site, then it will receive the HSTS pin, and the attack will no longer work when the user visits Sniffly.
When an image gets blocked by CSP, its onerror handler is called. In this case, the onerror handler does some fancy tricks to time how long it took for the image to be redirected from HTTP to HTTPS. If this time is on the order of a millisecond, it was an HSTS redirect (no network request was made), which means the user has visited the image's domain before. If it's on the order of 100 milliseconds, then a network request probably occurred, meaning that the user hasn't visited the image's domain.

由於這個技巧，HTTPS Everywhere 必須關閉才會比較準確。

Wikimedia (包括維基百科) 推出 HSTS (強制使用 HTTPS)

Wikimeda 宣佈所有旗下的網站都會啟用 HTTPS 與 HSTS：「Securing access to Wikimedia sites with HTTPS」。

在這之前，使用者可以用 EFF 的 HTTPS Everywhere 強制使用 HTTPS (在 Firefox 與 Google Chrome 都有上架)，而這次則是全面強制使用了。

愈來愈多人使用 HTTPS 來保護隱私後 (而不僅僅是保護機密資料)，接下來的問題就是要想辦法在 DNS 上保護了。也就是可以利用 DNS query pattern 知道你在看哪種 (或是哪一個) 頁面。