關於各家 ACME client (或者說 Let's Encrypt client?)

在「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」這邊引用的文章本來在討論又多了一家免費的 SSL certificate 可以用,但結果討論的主力都在講除了 Certbot 外還有什麼比較好用...

大家之所以厭惡 Certbot,先不講他需要依賴一堆 Python 的套件包,最主要的問題在於現在 Certbot 官方建議的指引裡面都要求你裝 Snap,而 Snap 這東西超級吃資源...

既然是資源問題,裡面可以看到 Dehydrated 又被拿出來推薦了,另外也有提到 acme.sh,不過我個人不太愛 acme.sh,主要是預設值跑去用 ZeroSSL 的 CA。

這種單檔就可以跑的很適合包進像是 Ansible 這類的管理工具,至少目前用起來沒什麼大問題...

Psst:Open Source 且非 Electron 版本的 Spotify 播放器

前幾天在 Hacker News 首頁上看到的東西,而且也是當天熱度超高的話題,Open Source 且非 Electron 版本的 Spotify 播放器 Psst:「Psst: Fast Spotify client with native GUI, without Electron, built in Rust (github.com/jpochyla)」。

因為使用 Rust 與 native GUI library,加上沒有一堆 Spotify 內建的廣告系統,整個速度快到爆炸 XDDD

專案的擁有者 jpochyla 在「make provided binaries more prominent #89」這邊有提到有 nightly build 可以用:「nightly.link | Repository jpochyla/psst | Workflow build.yml | Branch master」,不過我抓下來發現不會動,所以就自己花了些時間編看看...

剛被推上 Hacker News 的時候 README.md 上的指示還沒那麼清楚,編不起來,後來這兩天陸陸續續被修正了。

桌機是 Ubuntu 20.04,而用 Ubuntu 20.04 內包的 rustc (1.51.0) 是沒辦法編的,需要自己先透過 rustup 裝新版 1.54.0 來編,基本上照著 README.md 的指示先把 dependency 裝起來,然後照著對應的指令操作就可以了。

這樣之後聽音樂方便不少...

Elasticsearch 的 Python 套件開始阻擋 OpenSearch 的伺服器了

Hacker News Daily 上看到的:「Official Elasticsearch Python library no longer works with open-source forks (github.com/elastic)」,連結所指向的是 GitHub 上的 pull request,在「Verify connection to Elasticsearch #1623」這邊。

講白了也就是 Elasticsearch 官方的 Python client 開始阻擋 AWS 主推的 OpenSearch

另外 AWS 這邊也出手,把本來的 client 都 fork 出來:「Keeping clients of OpenSearch and Elasticsearch compatible with open source」,這場戰爭還有得打...

在 AWS 上面的 OpenVPN Server 效能

這篇的後續可以參考「Amazon EC2 的網路效能」這篇。

最近在在調整跑在 Amazon EC2OpenVPN server 的效能,要想辦法把 network throughput 拉高,當作在導入 WireGuard 之前的 workaround,但看起來還是頗有用,記錄一下可以調整的部份...

在還沒灌大量流量前是用 t3a.nano (開 Unlimited mode),然後會觀察到的瓶頸是 OpenVPN 的 daemon 吃了 100% CPU loading,最高速度卡在 42MB/sec 左右。

第一個想到的是看看 OpenVPN server 有沒有可以使用多 CPU 的方式,但查了資料發現 OpenVPN server 無法使用 threading 或是 fork 之類的方法善用多顆 CPU,所以就開始想其他方法...

接著看到我們目前用的是 AES-256-CBC 了,網路上很多文章都有提到 AES-128-CBC 會快一些,但我們的 OpenVPN client 已經是設死都用 AES-256-CBC 了,這個就沒辦法了...

而第一個可行的解法是把 AMD-based 的 t3a.nano 換成 ARM-based 的 t4g.nano,還是 100% 的 CPU loading,但直接多了 50%+ 的效能,到了 69MB/sec。

第二個解法是找資料時發現的 fast-io 參數,加上去以後可以再快一些,到 77MB/sec。

有了這兩個 workaround 應該就堪用了,接下來是發現在傳大量資料跑一陣子後速度會掉下來,於是開了兩台 t4g.nanoiperf 對測了一下,發現會逐步掉速:

  • 前 15 秒可以直接到 5Gbps,就是 AWS 網頁上宣稱的最高速度,接下來降到 800Mbps 左右。
  • 到 180 秒左右後降到 300Mbps。
  • 到 210 秒左右後回到 800Mbps。
  • 到 300 秒左右後降到 500Mbps。
  • 到 300 秒左右後降到 300Mbps。
  • 到 1260 秒左右後降到 30Mbps,後面就一直維持這個速度了。

看起來 network bandwidth credit 是分階段的,但 30Mbps 真的有點低...

在換成四倍大的 t4g.small 測試後發現也只能到 40MB/sec 左右 (比較疑惑的是,居然不是四倍?),目前上了 c6g.medium,但看起來網路的部份也還是有瓶頸,在 46MB/sec 左右,要再想一下下一步要怎麼調整...

但以目前看到的情況總結,如果能用 ARM 架構就儘量用,效率與價錢真的是好 x86-64 不少...

Mac OS 7/8/9 上的 SSH client

Hacker News 首頁上看到「Ssheven: A modern SSH client for Mac OS 7-9 (github.com/cy384)」這個,為了 Mac OS 7/8/9 (PowerPC 平台) 實做 SSH client。

翻了一下程式碼,看起來是透過 libssh2 實做加解密的部份,依照 libssh2 的官網,支援的演算法雖然不是超級新,但看起來還算可以 (至少有目前還算安全的演算法可以用):

Hacker News 上有看到一些老機器跑出來玩 XD

tikwidd 8 hours ago

So far it's working well on my LC III (68030 with 36mb ram)!
I'm writing this comment from the LC III using w3m over ssh :)

英國的 ISP 開始記錄使用者的連線資訊

從「Two UK Broadband ISPs Trial New Internet Snooping System」這邊看到英國的 ISP 開始記錄使用者的連線資訊,簡化後的 log 樣子像是這樣:

Two unnamed broadband or mobile ISPs are reportedly helping the UK Home Office and the National Crime Agency (NCA) to trial a new internet snooping system on their customers, which is being conducted as part of the controversial 2016 UK Investigatory Powers Act (aka – snoopers charter).

加上「T-Mobile US 打算要賣使用者的瀏覽記錄了」這篇,繼續推廣 DNS over HTTPDNS over TLS,以及 ECH (Encrypted Client Hello)。

Firefox 也打算淘汰 ESNI,改推 ECH

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。

Cloudflare 改推 ECH 加密整個 TLS 的 ClientHello

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 一樣...

可以等著看,到時候在中國的效果如何了,會不會讓國外的各大服務直接打進去呢...

Dehydrated 使用 ZeroSSL 的方式

上一篇「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」提到 ZeroSSL 的服務,而各家 acme client 也都陸陸續續支援了。

Dehydrated 是在 2020/09/15 的時候實做:「EAB + ZeroSSL support」,我就抓了個新版,更新之前自己包的 PPA dehydrated-lite...

Dehydrated 的設定方式還蠻簡單的,在 /etc/dehydrated/config 裡面這樣寫:

CA=zerossl
EAB_HMAC_KEY=x
EAB_KID=y

其中兩個 EAB 的資訊可以在 ZeroSSL 網站上面取得,然後其他就照舊跑...

Mutt 跳版推出 2.0

看到「Mutt 2.0 released」這篇,Mutt 推出 2.0 版,官方的 release notes 則是在這:「Mutt 2.0 Release Notes」。

這次版本跳到 2.0 主要是因為有 incompatible changes,實質上的變更其實沒有太多:

This release was bumped to 2.0, not because of the magnitude of features (which is actually smaller than past releases), but because of a few changes that are backward incompatible.

我自己還是保留一個信箱用 Mutt 在看信,主要是有一個信箱是完全控制在自己手上,所以自己架設 mail server 並且在上面看信...

上面主要是透過 procmail 拿來收各種信件 (尤其是 mailing list),對於純文字的閱讀還是頗方便...