幹壞事是進步最大的原動力
在 Neovim 時操作檔案名稱時會是下拉選單，在 insert mode 時的畫面是這樣 (進到 insert mode 後 Ctrl-X + F)：
這時候可以用上下鍵選擇檔案名稱。
在 command mode 下也有類似的功能，像是 :sp 後按 tab 選擇檔案名稱：
問題在於只能用 Ctrl-N 與 Ctrl-P 移動，而不能用上下鍵操作，兩者的 UI 類似但是操作的方式不一樣，於是就翻了翻 manual，找出對應的模式，得到是 command mode，然後用 <expr> + pumvisible() 判斷是否是在 popup menu，接著把上下鍵對應到 Ctrl-N 與 Ctrl-P：
cnoremap <expr> <Down> pumvisible() ? "\<C-n>" : "\<Down>" cnoremap <expr> <Up> pumvisible() ? "\<C-p>" : "\<Up>"
這樣就搞定了...
先前在「Chromium (Google Chrome) 實做對 Root DNS 的影響」這邊有提過 Chromium (以及 Google Chrome) 判斷所在的網路是不是有 NXDOMAIN hijack 的程式碼反而對 Root name servers 產生了巨大的 NXDOMAIN 流量。
因為上新聞所以才動了起來 (本來都沒什麼在動)，後來提供的方法是變成可以設定的選項，但預設是關閉的，這樣一來就可以改善 Root name servers 的壓力：「Add multi-state DNS interception policy - functionality piece.」。
而後在 Google Chrome 87 版進入 stable channel 後開始大幅緩解 (各平台分別在 2020/11/17 與 2020/11/18 釋出)，在繼續觀察幾個月後，上個禮拜 Verisign 的人在 APNIC 這邊更新了消息：「How Chromium reduced Root DNS traffic」。
這是去年八月時丟出來的資料，可以看到趨勢往上：
這是後續的資料，從 87 版釋出後開始往下：
另外我覺得比較好玩的是這個，在「Issue 1090985: Disable Intranet Redirect Detector by default」這邊看到這樣的說明：
看起來沒什麼問題，先 merge 再說... 是這樣玩嗎 XDDD
Firefox 也打算放棄 ESNI，改推 ECH 了：「Encrypted Client Hello: the future of ESNI in Firefox」。
目前的 85 版 (目前的 beta) 支援了 ECH draft-08，想要玩看看的人就可以測試了：
Firefox 85 replaces ESNI with ECH draft-08, and another update to draft-09 (which is targeted for wider interoperability testing and deployment) is forthcoming.
另外一個要看的當然就是 Google 家的 Chromium 了，不過這個協定對 Google 的誘因應該是超大，有機會直接穿入中國市場... 只是不知道會不會自己搞一套 protocol。
也是個大家等蠻久的功能，AWS 總算在 Amazon Route 53 上推出 DNSSEC 了：「Announcing Amazon Route 53 support for DNSSEC」。
他需要掛 AWS KMS，這部份會有一些費用在裡面，不過應該是還好...
不過 web console 目前有個明顯的缺點：透過 Route 53 註冊的網域，又用 Route 53 自家服務的情況下，設定 DNSSEC 的整合沒有做的很好，不能直接快速設定。
現在得自己設定演算法，然後複製 public key 到另外一邊，當你有一堆網域要設定的時候就會覺得很煩了...
Cloudflare 本來在推的 ESNI 現在變成 ECH 了：「Good-bye ESNI, hello ECH!」。
上面這張圖是 ESNI，下面這張是 ECH：
可以看出來 ECH 最主要的差異是把本來的 ClientHello 都加密包起來了，伺服器會先試著解內層的 ClientHelloInner，失敗的時候會用外層的 ClientHelloOuter：
The server completes the handshake with just one of these ClientHellos: if decryption succeeds, then it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter.
看得出來 ECH 的其中一個目標是讓他看起來跟一般的 TLS 連線一樣，這樣就能順便解掉 censorship 的問題...
其中一個原因應該也是因為之前中國與俄國的直接封掉 ESNI：
In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic.
In October 2020, Russian ISPs such as Rostelecom and its mobile operator Tele2 started blocking ESNI traffic.
不過仍然還有分析 HTTPS pattern 的方式可以抓 (就是文章裡提的 traffic analysis)，目前看起來只處理了 ClientHello 本身，現在還是有機會分析 handshake 過程來擋，必須繼續改善 ECH 的協定，讓整個流程看起來都跟一般的 TLS 一樣...
可以等著看，到時候在中國的效果如何了，會不會讓國外的各大服務直接打進去呢...
在 Hacker News 上看到的方式：「Which DNS」，另外在「Show HN: Which DNS servers are you pointing to? (nameserve.rs)」這邊也有一些討論。
這個方式是去抓 DNS server 對外的 IP，像 HiNet 的 168.95.1.1 這種 DNS server 後面都有一堆 resolver，這個方式可以知道出去的 IP 是哪個，可以幫助分析 routing 之類的問題...
記得 Akamai 有類似的服務，不過查了一下沒找到之前有印象的那個，反倒是查到另外一組可以用的：「Introducing a New whoami Tool for DNS Resolver Information」。
在 Hacker News Daily 上看到的，Debian 的 Wiki 上有一頁整理了很多「比較特別的」軟體或是指令的名稱由來：「WhyTheName」。
像是 Git：
git
(distributed VCS) semi-arbitrary short word
不過這邊不像維基百科會要求「可供查證」，裡面大多都沒有引用來源，真的要引用前最好還是去其他地方確認過...
看到「Setting Up Git Identities」這篇，裡面提到的方法可以解決 Git 裡有多個身份時常見的用錯身份的問題...
個人的 Git repository 會希望用自己的 email address，而公司的 Git repository 則是希望用公司的 email address，但 Git 預設會使用 username 與 hostname 組一個出來，所以常常是推到公司的機器上後才發現 Git repository 沒設定公司的 email address...
上面提到的文章就是關掉 Git 預設會組合的行為，於是就會記得要設定了：
git config --global user.useConfigOnly true
然後記得要把全域設定裡的 name 與 email 拔掉，另外有些人可能會掛上 signingkey 也一起拔掉：
git config --global --unset user.name git config --global --unset user.email git config --global --unset user.signingkey
這樣當沒設定時想要 git commit，就會被擋下來要求你提供，就能避免把自己的 email address 混在公司的 Git repository 裡面了...
Let's Encrypt 發現在檢查 CAA 的程式碼有問題，發了說明：「2020.02.29 CAA Rechecking Bug」，以及預定的處理方式：「Revoking certain certificates on March 4」。
問題是當一個 certificate request 包含了 N 個 domain 時，本來的 CAA 檢查應該要對這 N 個檢查，但程式寫成只會抓一個，然後檢查了 N 次：
The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.
2020/02/29 發現的，就程式碼的部屬時間，發現應該從去年 2019/07/25 開始就有這個 bug：
We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We deployed a fix at 05:22 UTC and then re-enabled issuance.
Our preliminary investigation suggests the bug was introduced on 2019-07-25. We will conduct a more detailed investigation and provide a postmortem when it is complete.
然後決定要 revoke 這些可能會有問題的 SSL certificate，大約佔現有還有效的 SSL certificate 的 2.6%，大約三百萬筆：
Q: How many certificates are affected?
A: 2.6%. That is 3,048,289 currently-valid certificates are affected, out of ~116 million overall active Let’s Encrypt certificates. Of the affected certificates, about 1 million are duplicates of other affected certificates, in the sense of covering the same set of domain names.
在「Check whether a host's certificate needs replacement」這邊可以偵測線上使用的 SSL certificate 是否受到影響。
另外在「Download affected certificate serials for 2020.02.29 CAA Rechecking Incident」這邊可以抓到所有受到影響，預定要 revoke 的 SSL certificate 的序號。關於取得序號的方式，官方也有提供 CLI 的指令可以操作確認，對於有很多網域名稱需要確認的人可以用這組指令編寫程式判斷：
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :
照目前的描述，如果申請時只有一個 domain 應該是不會中這個問題，再來是最壞的情況大概會維持三個月 (網站主人沒管他，等到時間到了自動 renew)。
在 Slack 上看到同事丟出來的，關於之後要推出的 iOS 13 與 macOS 10.15 會對憑證限制的項目：「Requirements for trusted certificates in iOS 13 and macOS 10.15」。
主要是把不安全的演算法淘汰掉 (RSA 小於 2048 bits，以及 SHA-1 類的 hash algorithm)，這兩個部份相關的新聞應該不少，沒有什麼太大問題：
TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.
TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.
然後是要求憑證使用 SAN (Subject Alternative Name)，舊的標準 CN (CommonName) 將不會再被信任。
如果是公開簽發的憑證應該都沒問題 (像是 Let's Encrypt，或是花錢買的那些)，主要的問題應該會出現在自己建立的憑證，網路上蠻多舊資料還是產生 CN...
TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.
另外是 2019/7/1 之後發出的憑證，有額外兩個規範要注意，第一個是強制要透過 EKU 指定 id-kp-serverAuth，這是出自 RFC 5280：
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
再來是時間的限制，接下來的憑證最長只認得 825 天 (大約 27 個月多一些)，以前都惡搞 -days 3650，現在得兩年簽一次了：
TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).
整體看起來主要是影響自己簽的部份...