ALB 支援 SNI

AWS 宣佈 ALB 支援 SNI 了:「Application Load Balancers Now Support Multiple TLS Certificates With Smart Selection Using SNI」。

不過這篇比較有趣的是,他範例用的是 VimIsBetterThanEmacs.comVimIsTheBest.com 這兩個網域名稱 XDDD:

I’ll use a few example websites like VimIsBetterThanEmacs.com and VimIsTheBest.com. I’ve purchased and hosted these domains on Amazon Route 53, and provisioned two separate certificates for them in AWS Certificate Manager (ACM). If I want to securely serve both of these sites through a single ALB, I can quickly add both certificates in the console.

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

在 Git/Mercurial/Subversion 上 "-" 發生的問題

在「[ANNOUNCE] Git v2.14.1, v2.13.5, and others」這邊看到 - 開頭產生的問題:

These contain a security fix for CVE-2017-1000117, and are released in coordination with Subversion and Mercurial that share a similar issue. CVE-2017-9800 and CVE-2017-1000116 are assigned to these systems, respectively, for issues similar to it that are now addressed in their part of this coordinated release.

這算是老問題了,Git 對應的修正主要是朝 filter input 的方向修正,包括了禁用 - 開頭的 hostname,以及禁止 GIT_PROXY_COMMAND- 開頭,另外是禁止開頭是 - 的 repository name:

  • A "ssh://..." URL can result in a "ssh" command line with a hostname that begins with a dash "-", which would cause the "ssh" command to instead (mis)treat it as an option. This is now prevented by forbidding such a hostname (which should not impact any real-world usage).
  • Similarly, when GIT_PROXY_COMMAND is configured, the command is run with host and port that are parsed out from "ssh://..." URL; a poorly written GIT_PROXY_COMMAND could be tricked into treating a string that begins with a dash "-" as an option. This is now prevented by forbidding such a hostname and port number (again, which should not impact any real-world usage).
  • In the same spirit, a repository name that begins with a dash "-" is also forbidden now.

然後中華電信的 DNS server (168.95.1.1 & 168.95.192.1) 都查不到 marc.info,改用 Google 的 8.8.8.8 才查得到... =_=

直接接管整個 .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...)

StackOverflow 對於多 DNS 商的同步方式...

他們的解法是設計出一套 DSL (Domain Specific Language),然後從 DSL 轉出各 DNS 商的格式:「Introducing DnsControl – “DNS as Code” has Arrived」。

stackoverflow.com 來說,可以看到有同時使用 AWSRoute 53GoogleCloud DNS

;; ANSWER SECTION:
stackoverflow.com.      36458   IN      NS      ns-cloud-e2.googledomains.com.
stackoverflow.com.      36458   IN      NS      ns-358.awsdns-44.com.
stackoverflow.com.      36458   IN      NS      ns-1033.awsdns-01.org.
stackoverflow.com.      36458   IN      NS      ns-cloud-e1.googledomains.com.

於是他們就用 DSL 管理:

D(“stackoverflow.com”, REG_NAMEDOTCOM, DnsProvider(R53), DnsProvider(GCLOUD),
    A(“@”, “198.252.206.16”),
    A(“blog”, “198.252.206.20”),
    CNAME(“chat”, “chat.stackexchange.com.”),
    CNAME(“www”, “@”, TTL(3600)),
    A(“meta”, “198.252.206.16”)
)

這套程式碼在「StackExchange/dnscontrol」這邊,但這樣搞有種微妙的感覺... 不考慮直接用兩家有支援 AXFR 架構的 DNS 商來架設嗎?這樣就只要用 BIND 這類已經很熟悉的軟體設定就好?

Netflix 的 BetterTLS,推廣 CA 的 Name Constraints

Netflix 因為想用 Name Constraints,所以決定自己跳出來推廣了:「BetterTLS - A Name Constraints test suite for HTTPS clients」。

就是在 CA 上可以綁定條件,只允許哪些 domain 可以被發放:

網站在「BetterTLS: Name Constraints」這邊可以看。

線上測試 SQL Injection 喔喔喔

在「An SQL Injection Attack Is a Legal Company Name in the UK」這邊看到英國的這家公司:「; DROP TABLE "COMPANIES";-- LTD」,根本就是在幫大家測試 XDDD

當然,大家也都馬上聯想到這則 xkcd 漫畫:「Exploits of a Mom」。

來招喚 QQ 姊翻譯這則 xkcd 漫畫?

Let's Encrypt 支援 IDN

Let's Encrypt 宣佈支援 IDN:「Introducing Internationalized Domain Name (IDN) Support」,這代表可以申請的範圍變得更廣了:

This means that our users around the world can now get free Let’s Encrypt certificates for domains containing characters outside of the ASCII set, which is built primarily for the English language.

在「Upcoming Features」可以看到下一步應該是 ECDSA Intermediates?

Let’s Encrypt only signs end-entity certificates with RSA intermediates. We will add the ability to have end-entity certs signed by an ECDSA intermediate.

不曉得之後還會有什麼功能...

CA/Browser Forum 在三月底的會議記錄

CA/Browser Forum 三月底的會議記錄裡看到了關於 wildcard ssl certificate 的一些討論,還蠻有趣的:「2016-03-31 Minutes」。

主要是第五條的記錄,在討論更廣泛的 wildcard 用法。首先是 Microsoftww*.example.com 這種 domain 的認定:

Rick said there was a Microsoft tech note that allows ww*.example.com. Jody confirmed the platform supports it.

但有爭論,而且目前看起來暫時沒有打算要實作:

Rick suggested the BRs be updated to include that. Ryan said that is not a good thing as there are multiple specs that treat this differently and historical context which would make it hard for Google to support such a ballot. Kirk asked why Peter put this in the ballot. He responded that this was raised in the past where people found a discrepancy in relation to other docs. However, given there was not consensus, he would remove from the proposed ballot. Ryan said there is a need for clarification because CAs seem to be interpreting this differently. Peter said he would create a new definition called “wildcard domain name” with an exact definition to avoid confusion and add clarity. Rick said that ideally Microsoft should remove that functionality and update the tech notes. Jody said he would need to consult with his expert on this. Peter said the goal of this ballot was to make it a “consensus” ballot and would remove anything controversial.

看起來還沒有完全定下來,之後的會議記錄可以再看看進展。這對安全性也頗有幫助,舉例來說,我就可以針對不同的服務發不同的 wildcard ssl certificate,像是 test-*.example.com 這樣,而不用另外再建立機制避免 private key 的外流。

Route53 的 Health Check 支援 HTTPS SNI 了...

Route53 的 Health Check 總算支援 SNI 了:「Amazon Route 53 Adds SNI Support for HTTPS Health Checks」。

With SNI and HTTPS support, you can now create health checks for secure websites that rely on SNI to serve the correct website and certificate to requests for a particular domain name.

這功能早該出現啦,等好久了...