Home » Posts tagged "hsts"

Google 開放 .app 註冊,是個 HSTS Preload TLD

Google 宣佈了 .app 的網域將開放註冊:「Introducing .app, a more secure home for apps on the web」。

整個 .app 網域都已經被 Google 設定 HSTS Preload 了:

A key benefit of the .app domain is that security is built in—for you and your users. The big difference is that HTTPS is required to connect to all .app websites, helping protect against ad malware and tracking injection by ISPs, in addition to safeguarding against spying on open WiFi networks. Because .app will be the first TLD with enforced security made available for general registration, it’s helping move the web to an HTTPS-everywhere future in a big way.

如果要註冊下來,開發的時候得注意...

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。

WebKit 對 HSTS Super Cookie 提出的改法

Twitter 上看到 WebKitHSTS 所產生的 Super Cookie 提出的改善方案:

拿原文的例子來說明,先指定一個隨機數給 user,像是 8396804 (二進位是 100000000010000000000100),所以就存取下面的網址:

https://bit02.example.com
https://bit13.example.com
https://bit23.example.com

在存取這些 HTTPS 網址時都會指定 HSTS,所以之後連到這三個網址的 HTTP request 就不會觸發到 HTTP 版本,會因為 HSTS 被轉到 HTTPS 版本。於是就可以用 32 個 HTTP request 測試 32bits 而判斷出身份。(當然你可以用更多)

WebKit 提出的改善方案大概有幾種,主要是就觀察到的現象來限制。

第一種解法「Mitigation 1: Limit HSTS State to the Hostname, or the Top Level Domain + 1」是因為會看到這樣的設計:

https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.a.example.com
https://a.a.a.a.a.a.a.example.com
…etc...
https://bit00.example.com
https://bit01.example.com
https://bit02.example.com
...etc...
https://bit64.example.com

所以提出的方案是只有目前網站的 domain 以及 top domain + 1 (像是 example.com) 可以被設定 HSTS:

Telemetry showed that attackers would set HSTS across a wide range of sub-domains at once. Because using HSTS in this way does not benefit legitimate use cases, but does facilitate tracking, we revised our network stack to only permit HSTS state to be set for the loaded hostname (e.g., “https://a.a.a.a.a.a.a.a.a.a.a.a.a.example.com”), or the Top Level Domain + 1 (TLD+1) (e.g., “https://example.com”).

但其實廣告主只需要註冊 32 domains (或是 64) 就可以避開這個問題。

第二種是「Mitigation 2: Ignore HSTS State for Subresource Requests to Blocked Domains」,如果在 HTTPS 頁面上,某個 domain 的 cookie 已經因為某些原因被阻擋 (像是手動設定),那麼就忽略掉 HSTS 的設計:

We modified WebKit so that when an insecure third-party subresource load from a domain for which we block cookies (such as an invisible tracking pixel) had been upgraded to an authenticated connection because of dynamic HSTS, we ignore the HSTS upgrade request and just use the original URL. This causes HSTS super cookies to become a bit string consisting only of zeroes.

後面這點在現在因為 SEO 設計而使得各大網站都往 HTTPS 方向走,應該會有些幫助吧...

本來 Google Chrome 要繞過 HSTS 的 badidea 被換掉了...

先前在「在 Google Chrome 連上因 HSTS 而無法連線的網站」中提到的關鍵字 badideaGoogle Chrome 65 發現沒用了,找了一下發現是被換掉了:「Chrome 65 replaces the "badidea" bypass keyword with "thisisunsafe"」,這 Reddit 的標題就說明了換成什麼了 XDDD

而且從 source code 裡面可以看到,本來是明碼的 badidea,改用 window.atob 來存了:「Diff - d8fc089b62cd4f8d907acff6fb3f5ff58f168697^! - chromium/src - Git at Google」。

anyway,要記其他的字串了 XDDD

LinkedIn 忘記續約導致 SSL Certificate 過期

Netcraft 上看到 LinkedIn 出包的消息,這次是 country-mixed 的版本出包:「LinkedIn certificate blunder leaves users LockedOut!」。

在 DNS 上也可以看出來這兩個 CNAME 到不一樣的 load balancer 上:

;; ANSWER SECTION:
www.linkedin.com.       260     IN      CNAME   2-01-2c3e-003c.cdx.cedexis.net.
2-01-2c3e-003c.cdx.cedexis.net. 93 IN   CNAME   pop-ehk1.www.linkedin.com.
pop-ehk1.www.linkedin.com. 3560 IN      A       144.2.3.1
;; ANSWER SECTION:
de.linkedin.com.        86400   IN      CNAME   cctld.linkedin.com.
cctld.linkedin.com.     86400   IN      CNAME   mix.linkedin.com.
mix.linkedin.com.       213     IN      CNAME   pop-ehk1.mix.linkedin.com.
pop-ehk1.mix.linkedin.com. 3546 IN      A       144.2.3.5

SSL Labs 上也看得出來在 Alternative names 的地方是不一樣的:「SSL Server Test: www.linkedin.com (Powered by Qualys SSL Labs)」、「SSL Server Test: de.linkedin.com (Powered by Qualys SSL Labs)」。

然後因為 LinkedIn 有設定 HSTS,所以使用者在界面上完全無法登入:

Google Chrome 上可以用 badidea 繞過 (參考「在 Google Chrome 連上因 HSTS 而無法連線的網站」),但在 Mozilla Firefox 上的話目前沒找到方法可以在界面上 bypass,而是需要改 SiteSecurityServiceState.txt 這個檔案:「HTTP Strict Transport Security prevents me from accessing a server that I'm doing development on」。

不過也因為兩個 cluster 獨立運作,網址改一下應該就會動了...

這幾年比較很少看到大公司出這種包,還蠻有趣的 XD

DHS 要求郵件系統都必須使用 STARTTLS、DMARC,並且全面禁用 RC4 與 3DES

Twitter 上看到 18F 貼了 DHS 的新規定:「Enhance Email and Web Security」。

郵件系統的部份,要求要有 STARTTLS,並且設定 SPFDMARC。另外禁用 SSLv2 SSLv3,以及 RC43DES

網站的部份,則是要求 HTTPS 以及 HSTS。另外也與郵件系統一樣禁用 SSLv2、SSLv3,以及 RC4 與 3DES。

不只 18F 一個單位在推動,這樣整體的速度才會加快...

Google 打算更廣泛的預設使用 HSTS

Google 宣佈了更廣泛開啟 HSTS 的計畫:「Broadening HSTS to secure more of the Web」。

然後先提到 .foo.dev 的「Google Chrome 將 .dev 設為 HSTS Preload 名單」這件事情:

In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.

接下來希望拋磚可以引玉:

We hope to make some of these secure TLDs available for registration soon, and would like to see TLD-wide HSTS become the security standard for new TLDs.

Google Chrome 將 .dev 設為 HSTS Preload 名單

其實是兩件事情... 第一件是 Google Chrome.dev 結尾的網域設為 HSTS Preload 名單:「Chrome to force .dev domains to HTTPS via preloaded HSTS」。

第二件事情是隨著第一件來的,HSTS Preload 必須由 domain 擁有人提出啊... 所以 .dev 是合法的 TLD (gTLD)?

文章作者給了答案,是的,而且就是 Google 擁有的:

Wait, there's a legit .dev gTLD?
Yes, unfortunately.

(翻白眼)

這對開發者來說有種無奈感...

不過你可以用這招避開:「在 Google Chrome 連上因 HSTS 而無法連線的網站」,也就是輸入 badidea

另外測試了一下,應該是所有的 A record 都會指到 127.0.53.53,如果有人懶得設定的話也可以用這個位置啦...

在 Google Chrome 連上因 HSTS 而無法連線的網站

Update (2018/03/15):字串改了,請參考「本來 Google Chrome 要繞過 HSTS 的 badidea 被換掉了...」。

像是把 StartCom 停用掉後造成 www.kernel.org 無法連線的問題:

前幾天在 Twitter 上看到解法:

說道 StartCom,StartCom 與 WoSign 的故事才剛要開始,前陣子在「Mozilla 在考慮移除 WoSign 的 CA Root」這邊提到的問題,最近 mailing list 上越來愈刺激了。(發現更多沒有通報的問題)

另外也發現 StartCom 被 WoSign (的 CEO) 買下來了,當初因為「Why I stopped using StartSSL (Hint: it involves a Chinese company)」而移除信任,看起來情況只會更糟糕...

Google 的 www.google.com 要上 HSTS 了

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

雖然都已經使用 EFFHTTPS 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.

Archives