July 2021 – Page 2 – Gea-Suan Lin's BLOG

Mitmproxy 7 支援 TLS over TCP 的分析了

在 Hacker News 首頁上看到 Mitmproxy 7 的消息：「Mitmproxy 7」。

比較重要的功能應該就是可以針對任意的 TLS 連線攔截分析了：

不過像是 STARTTLS 這類先在 plaintext 溝通，然後送出指令進入 TLS 的方式，目前就還沒支援：

Opportunistic TLS (STARTTLS) is not supported yet, but regular TCP-over-TLS just works!

另外是可以分析 WebSocket 內的傳輸資料：

應該是跑個 pip install -U mitmproxy 就可以升級了... (如果先前是用 pip 安裝的話)

在 Hacker News 上看到選擇公理

沒想到會在 Hacker News 的首頁上看到這麼硬核的主題，選擇公理 (Axiom of choice，通常縮寫成 AC)：「What is the Axiom of Choice?」，對應的討論在「What is the Axiom of Choice? (jaydaigle.net)」。

出自「xkcd: Set Theory」

應該是大一教集合論的時候學到的，算是一個非常重要的公設，雖然的確有些數學系統是可以假定 AC 不成立，但用起來會不太好用，主要是因為「對於集合 $S$ ，取出任意一個元素」這類用法太常出現，在沒有 AC 的情況下這件事情就不一定能操作了...

我們目前常用的數學一般是建立在 Zermelo-Fraenkel Set Theory (ZF) 這個公理系統加上 AC，簡寫變成 ZFC。而 AC 在集合論常常會被拿出來說明，主要還是因為在歷史上花了不少力氣才證明 ZF 與 AC 的相對協調性 (ZF 與 AC 不衝突)，以及 ZF 與 AC 獨立性 (ZF 無法推導出 AC)。

有了 AC 後就會再解釋連續統假設 (Continuum hypothesis，簡稱 CH)，也就是 $\mathbb{N}$ 與 $2^{\mathbb{N}}$ 之間存不存在一個集合 $S$ 使得 $|\mathbb{N}| < |S| < |2^{\mathbb{N}}|$ 。

然後再打臉一次，說明 ZFC 與 CH 的協調性 (ZFC 與 CH 不衝突)，與獨立性 (ZFC 無法推導出 CH)。

當時學的時候的確是很頭痛，不過現在回頭看倒是覺得很有趣：在數學上你可以證明「某個敘述無法被證明」，這點應該是以前沒想過的...

Ubuntu 環境 PPPoE 遇到拿的到 IPv6 address 但是卻不通的問題

在 Ubuntu 的環境裡透過 PPPoE 上拿 IPv6 address 不是什麼大問題，搜一下大概都可以找到，在 /etc/ppp/options 的最後面加上這串就可以了 (或是在 /etc/ppp/peers/ 裡面的檔案對特定的設定加)：

+ipv6 ipv6cp-use-ipaddr

不過我遇到的問題是，ppp0 雖然拿到了 IPv6 address (從 ip addr 或是 ifconfig 可以看到)，但 mtr -6 www.google.com 確不通。

找問題時發現 netstat -6rn 有兩筆 IPv6 default gateway，刪掉 enp3s0 的那筆馬上就通了，所以是跟 routing 有關的問題，在本地端收到了 default routing，優先權還比 ppp0 拿到的還高。

因為這台主機是跑 Netplan，所以就用 Netplan 的方式強制關掉本地端的 Router Advertisement (RA)：

network:
    version: 2
    renderer: networkd
    ethernets:
        enp3s0:
            accept-ra: false

最後重開機確認後就通了...

Chromium 系列瀏覽器對 Google Search Engine 的不公平最佳化

在 tab 上放了一陣子的連結，忘記是哪邊看到的，在講 Chromium 系列瀏覽器會針對 Google Search Engine 最佳化：「Google’s unfair performance advantage in Chrome」。

作者發現 Chromium 瀏覽器會預先開 HTTPS 連線連到搜尋引擎，這樣可以大幅降低建立 HTTPS 連線時所需要的時間，包括了 DNS 查詢、TCP handshake 與 TLS handshake：

I was looking for something else when I stumbled upon a feature called PreconnectToSearch. When enabled, the feature preemptively opens and maintains a connection to the default search engine.

問題在於這個功能只開給 Google Search 使用：

There’s just one small catch: Chromium checks the default search engine setting, and only enables the feature when it’s set to Google Search.

在 search_engine_preconnector.cc (HEAD 版本) 這邊可以看到這段程式碼：

// Feature to limit experimentation to Google search only.
const base::Feature kPreconnectToSearchNonGoogle{
    "PreconnectToSearchNonGoogle", base::FEATURE_DISABLED_BY_DEFAULT};
}  // namespace features

作者有提到，的確這個功能會對 search engine 有不小的衝擊，但可以透過擴充 OpenSearch Descriptions 或是 Well-Known URI 的方式提供，現在這樣寫死在程式碼裡面完全就是不公平競爭。

CloudFront 宣佈支援 ECDSA 的 Certificate

Amazon CloudFront 宣佈支援 ECDSA 的 certificate：「Amazon CloudFront now supports ECDSA certificates for HTTPS connections to viewers」。

用主要是讓 certificate 更小，讓 HTTPS 建立時的過程更快 (包括了傳輸的速度與計算的速度)：

As a result, conducting TLS handshakes with ECDSA certificates requires less networking and computing resources making them a good option for IoT devices that have limited storage and processing capabilities.

很久以前好像有看到資料說 256 bits 的 EC 運算量跟 768～1024 bits 的 RSA 差不多，但一時間找不到資料...

目前 CloudFront 只支援 NIST P-256 (secp256r1，或稱作 prime256v1)：

Starting today, you can use Elliptic Curve Digital Signature Algorithm (ECDSA) P256 certificates to negotiate HTTPS connections between your viewers and Amazon CloudFront.

但 NIST P-256 一直為人詬病，在「SafeCurves: choosing safe curves for elliptic-curve cryptography」這邊可以看到 NIST 宣稱的效率設計實際上都不是真的：

Subsequent research (and to some extent previous research) showed that essentially all of these efficiency-related decisions were suboptimal, that many of them actively damaged efficiency, and that some of them were bad for security.

但目前標準是往 NIST P-256、NIST P-384 與 NIST P-521 靠攏 (主要是受到 CA/Browser Forum 的限制)，要其他 curve 的 certificate 也沒辦法生，目前可能還是繼續觀望...

RabbitMQ 也進來搶 Streaming Engine 這塊市場了

RabbitMQ 要在 3.9 版推出 Streams (目前 3.9 還在 RC)：「RabbitMQ Streams Overview」，在 Hacker News 上有一些討論可以看：「RabbitMQ Streams Overview (rabbitmq.com)」。

這樣 RabbitMQ 可以同時有 queue 與 stream 的能力，對於一些小專案應該會方便不少，算是打隔壁棚 Kafka 的痛點之一，弄一組 HA cluster 至少要三台 ZooKeeper 加上兩台 Broker，基礎建設還要有對應的 HA load balancer 機制，在 AWS 上可以拿 ELB 偷懶，如果是實體機房的話也許用 F5 擋，或是用 open source 的 Keepalived (或是老一點的 Heartbeat) + nginx。

目前還不知道 scalability 的能耐，不過印象中在 queue 的單台 throughput 不差，如果沒有意外的話，streaming 的部份對小型專案應該夠用。

MySQL 跑在 ZFS 與 ext4 的效能差異

Percona 的「MySQL/ZFS Performance Update」這篇又對 ZFS 做了一次測試，算是用比較新的軟體跑出來的結果，不過要注意這邊的 ZFS 版本仍然不是目前最新版：

ZFS 0.8.6-1 is not bleeding edge, there have been more than 1700 commits since and after 0.8.6, the ZFS release number jumped to 2.0. The big addition included in the 2.0 release is native encryption.

機器是在雲端上 (Azure 上)，不熟悉 Azure 的機種，但看記憶體與 CPU 的量好像不是用頂規的機器：

benchmark host
Standard D2ds_v4 instance
2 vCpu, 8GB of Ram and 75 GB of temporary storage
Debian Buster

Database host
Standard E4-2ds-v4 instance
2 vCpu, 32GB of Ram and 150GB of temporary storage
256GB SSD Premium (SSD Premium LRS P15 – 1100 IOPS (3500 burst), 125 MB/s)
Debian Buster
Percona server 8.0.22-13

跑出來的結果看起來不差：

看了一下測試用的設定，似乎只測了 compression 的部份，沒測 snapshot 以及其他功能會對效能有什麼影響，但至少基本盤應該是還不錯？

Percona XtraDB Cluster (PXC) 節點離開太久後的惡搞法

在 Percona 的「How To Recover Percona XtraDB Cluster 5.7 Node Without SST」這邊看到的技巧，不過只能用在 5.7 版，不能用在 8.0 版。我猜這個方法也可以用在其他跑 Galera Cluster 的資料庫上...

維護一組 Percona XtraDB Cluster 時一個常見的問題是，當節點離線太久後有機會無法用 IST (Incremental State Transfer) 跟回來，也就是只要把先前還沒有同步的部份更新進資料庫的方法，這時候就會需要用 SST (State Snapshot Transfer)，變成抓整個 full copy。

作者提出來的方法是基於 IST 的大小通常比較小，但 binlog 通常都留蠻久的，所以可以利用 binlog 來幫 IST。

方法是先把 Galara Cluster 關掉，用 MySQL 傳統的 replication 同步到一定程度後，再把 IST 相關的位置設定指到已經同步的位置，接著再把 Galara Cluster 接上去就可以恢復了。

這個方法是 5.7 版限定，因為 8.0 的年代沒辦法改 Galara Cluster 的 wsrep 位置資訊：

Unfortunately, a similar solution does not work with Percona XtraDB Cluster 8.0.x, due to the modified way wsrep positions are kept in the storage engine, hence the trick with updating grastate.dat does not work as expected there.

我覺得可能 Percona 之後會弄出 patch 讓使用者可以改...

在 netsplit 的統計上，Libera.Chat 已經超過 freenode 了

翻了一下「IRC Network Libera.Chat」與「IRC Network freenode」：

During last connections to Libera.Chat its servers reported an average of 40267 users and 19125 chat rooms. Use the following menu to get more information about IRC network Libera.Chat! Take a view to the generated statistics and search within the list of chat rooms for topics of your interest!

During last connections to freenode its servers reported an average of 26145 users and 23410 chat rooms. Use the following menu to get more information about IRC network freenode! Take a view to the generated statistics and search within the list of chat rooms for topics of your interest!

一陣子沒關注，發現已經甩開了...

Neovim 在選擇檔案名稱時的操作按鍵

在 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>"

這樣就搞定了...