Google 的 .search 網域

Netcraft 的「November 2017 Web Server Survey」這篇看到關於 Google 弄到的 .search 網域:

This month the controversial new .search gTLD being run by Google’s Charleston Road Registry subsidiary was found for the first time, with www.nic.search responding to the survey. Google hopes it will be able to run .search as a dotless domain which will automatically redirect users to their search engine of choice. This proposal has been criticised for going against ICANN’s own rules, which prohibits this functionality due to the potential for conflicts with existing names on internal networks. This feature could also cause confusion for users who have come to expect that typing words into their address bar will perform a search query for that term.

It is currently uncertain whether or not Google will be allowed to run the .search TLD as a dotless domain, however with the launch of the first site on this TLD this month Google is one step closer to the provision of this service.

找了一下資料,ICANNWiki 上的「.search」有些資料,另外也有新聞資訊 (2013 年的):「Google Wants To Operate .Search As A “Dotless” Domain, Plans To Open .Cloud, .Blog And .App To Others」。

不太妙...

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,如果有人懶得設定的話也可以用這個位置啦...

直接接管整個 .io 的網域...

在「The .io Error – Taking Control of All .io Domains With a Targeted Registration」這邊看到的 XDDD

其實就是這樣:

;; AUTHORITY SECTION:
io.         172800  IN  NS  ns-a1.io.
io.         172800  IN  NS  ns-a2.io.
io.         172800  IN  NS  ns-a3.io.
io.         172800  IN  NS  ns-a4.io.
io.         172800  IN  NS  a0.nic.io.
io.         172800  IN  NS  b0.nic.io.
io.         172800  IN  NS  c0.nic.io.

然後他就去註冊 ns-a{1,2,3,4}.io 了 XDDD

這很歡樂 XDDD

(應該可以來掃一下所有的 tld...)

利用 Unicode Domain 釣魚,以及 Chrome 與 Firefox 的解法

一個多禮拜前引起蠻多討論的一篇文章,利用 Unicode Domain 釣魚的方法:「Phishing with Unicode Domains」。

由於這是幾乎完美的攻擊,所以被提出來後 (Security: Whole-script confusable domain label spoofing) 有不少討論:

This bug was reported to Chrome and Firefox on January 20, 2017 and was fixed in the Chrome trunk on March 24. The fix is included in Chrome 58 which is currently rolling out to users.

comment 8 提到:

We do have a whitelist. Essentially you're suggesting that we remove Cyrillic and Greek characters from the list. I'm not sure we want to go down that path.

在新版的 Chrome 58 已經「修正」了這個問題:

Firefox 的討論在「IDN Phishing using whole-script confusables on Windows and Linux」這邊,一開始就直接把票給關了 XDDD:

Indeed. Our IDN threat model specifically excludes whole-script homographs, because they can't be detected programmatically and our "TLD whitelist" approach didn't scale in the face of a large number of new TLDs. If you are buying a domain in a registry which does not have proper anti-spoofing protections (like .com), it is sadly the responsibility of domain owners to check for whole-script homographs and register them.

We can't go blacklisting standard Cyrillic letters.

If you think there is a problem here, complain to the .com registry who let you register https://www.xn--80ak6aa92e.com/ .

Gerv

Status: NEW → RESOLVED
Last Resolved: 3 months ago
Flags: needinfo?(gerv)
Resolution: --- → WONTFIX

然後一個月前被提出來看看 Chrome 怎麼做:

Gerv/Valentin, is this something we can/should align with Chromium on?

目前唯一的解法是改 flag,把所有的 Unicode Domain 直接當作一般的 domain 來處理,列出像是 www.xn--80ak6aa92e.com 的網址。

取得某些 tld 所有的 Domain Name

在「How to Download a List of All Registered Domain Names」這邊介紹了 .com、.net 以及 .name 的 zone file 怎麼申請與下載 (由 Verisign 維護的三個 tld)。

另外也介紹了 Centralized Zone Data Service,包括所有的 tld,以及 ICANN 提供的 API。

這樣應該有很多資料可以分析?

如果新的 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 看起來會是可能會參與的單位?