把 HTTP 站台逐步換向 HTTPS 站台的步驟

Jerry Qu 寫的「关于启用 HTTPS 的一些经验分享」這篇文章講了要怎麼將 HTTP 站台逐步換成 HTTPS 站台的方式 (以及工具)。

一開始會遇到 Mixed Content,瀏覽器預設值不會直接全部擋掉,而是會放行圖片類資源 (但是出現對應的警告)。然後可以用 upgrade-insecure-requests 來幫助邊換,讓 url 裡指定 http 的自動連到 https。

當全站把 url 都修完後,接著就可以考慮用 HSTS 強制全上 HTTPS。

做到這邊的安全性已經到一定程度了,接下來要不要進 HSTS Preload List 就看大家自己的想法了。

利用 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 必須關閉才會比較準確。

STARTTLS 的不完整性以及大規模監控電子郵件

在「Don’t count on STARTTLS to automatically encrypt your sensitive e-mails」這邊提到了 STARTTLS 的問題,引用「Neither Snow Nor Rain Nor MITM ... An Empirical Analysis of Email Delivery Security」這篇論文的說明。

SMTP 裡 STARTTLS 的設計雖然可以加密,但仲所皆知,可以阻擋 EHLO 回應結果避免建立 STARTTLS 連線,而讓發送端改用傳統未加密的 SMTP 傳輸。而研究發現其實目前就有大規模的這種監控行為:

可以看到突尼西亞的監控情況遠超過想像...

目前的想法是發展一套類似 HSTS 的 Trust on first use 設計,也許在這份報告出來後可以加速催生...

微軟讓 Windows 7 與 Windows 8.1 上的 IE11 支援 HSTS

本來只有 Windows 10 的 IE11 有支援 HSTS,而前幾天的更新則是讓 Windows 7 與 Windows 8.1 的 IE11 也支援了:「HTTP Strict Transport Security comes to Internet Explorer 11 on Windows 8.1 and Windows 7」。

With today’s monthly security updates (KB 3058515), we’re bringing the protections offered by HSTS to Internet Explorer 11 on Windows 8.1 and Windows 7. HSTS is also available in both Internet Explorer 11 and Microsoft Edge on Windows 10.

這次的更新讓所有主流瀏覽器都支援 HSTS 了,再加上前一篇「Wikimedia (包括維基百科) 推出 HSTS (強制使用 HTTPS)」提到的,愈來愈多人用啦...

然後據 zonble 說,iOS 9 有些東西會 HTTPS only (預設值),該回頭去催自己人支援了 :o

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

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

在這之前,使用者可以用 EFFHTTPS Everywhere 強制使用 HTTPS (在 FirefoxGoogle Chrome 都有上架),而這次則是全面強制使用了。

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

RFC7469:Public Key Pinning Extension for HTTP

前幾天的 Standards Track:「Public Key Pinning Extension for HTTP」。

HPKP (HTTP Public Key Pinning) 機制是讓 server 端在第一次連線時告訴 client (像是瀏覽器) Public Key 資訊,也就是建構在 TOFU (Trust-on-first-use):

Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)

機制上很像 HSTS (HTTP Strict Transport Security,RFC6797)。依據 Mozilla 的「Public Key Pinning」資料,目前新版的 Google ChromeFirefox 都有支援了。

Mozilla 提供了 SSL/TLS 設定懶人包

MozillaMozilla SSL Configuration Generator 提供了各種 server side 的設定:

以及不同等級的設定 (Modern、Intermediate、Old),另外還有 HSTS 的選項可以選擇。

對於 security 的東西我不是很喜歡用 generator (因為我覺得既然是資安相關的東西,要盡可能知道每個細節),但算是一種推廣吧,看了一下設定也都還算合理...

CloudFlare 的 HTTPS 支援 HSTS 設定

CloudFlareHTTPS 支援 HSTS:「Enforce Web Policy with HTTP Strict Transport Security (HSTS)」。

目前可以設 max-ageincludeSubDomains。至於 preload 還在規劃。不算複雜的功能 (加上 HTTP header),不過對於安全性的幫助很大。

不過 origin 好像也可以送,不知道 CloudFlare 會不會濾掉...

如果新的 TLD 都強制要求使用 HTTPS (HSTS)?

GoogleAdam Langley 在他的 blog 上提出了一個很特別的想法,是不是把現在這些新增加的 TLD 都預先在瀏覽器裡納入 HSTS:「HSTS for new TLDs」。

Here's an idea: why not ask me to set HSTS for the entire TLD? That way, every single site runs over HTTPS, always. It strikes me that could be useful if you're trying to build trust with users unfamiliar with the zoo of new domains.

只要任何一個比較大的 browser 這樣做,其實就相當於強制要求?看文章內的語氣,Firefox + Google Chrome 看起來會是可能會參與的單位?