PHP 8 將會移除 XML-RPC,改放到 PECL 內

Twitter 上看到「PHP RFC: Unbundle ext/xmlrpc」這則消息,PHP 官方打算把 XML-RPC (也就是 git repository 裡面的 ext/xmlrpc) 拆出去,移到 PECL

Unbundle ext/xmlrpc (i.e. move it to PECL) without any explicit deprecation.

主要的考慮是在於目前的 library 已經年久失修:

ext/xmlrpc relies on on libxmlrpc-epi, which is abandoned. Even worse, we are bundling a modified 0.51, while the latest version is 0.54.1. This is exacerbated by the fact that the system library is usually built against libexpat, but the bundled library is likely to be built against libxml2 using our compatibility layer.

另外應該也是因為 XML-RPC 用的人不多吧,投票是沒什麼玄念的 50:0,而且在 Packagist 上面也可以翻到一些用 PHP 實做的替代品,拿 xmlrpc 這個關鍵字搜了一下可以看到一些...

WireGuard 的 OpenBSD porting

在「WireGuard patchset for OpenBSD」這邊看到有人試著把 WireGuard 放入 OpenBSD 的消息。

整包 patchset 包括了 kernel 與 userland 的實做,可以在 mailing list 上「WireGuard patchset for OpenBSD」這邊可以看到,整串討論可以在「'WireGuard patchset for OpenBSD' thread - MARC」這邊看到,目前看起來還在 code review 的階段,有看到討論提到應該用 OpenBSD 內已經實做的 Chacha20-Poly1305,所以可能還會需要一些時間...

看起來慢慢的在滲進每個作業系統中,蠻有希望在幾年後成為業界標準...

棄用 Keybase (Zoom 買下 Keybase 的新聞)

前幾天的新聞,Zoom 的新聞稿:「Zoom Acquires Keybase and Announces Goal of Developing the Most Broadly Used Enterprise End-to-End Encryption Offering」,Keybase 的新聞稿:「Keybase joins Zoom」,看到後就把本來的服務刪一刪了...

這篇屬名由 Zoom 創辦人發出的公告,裡面多到讓人不知道怎麼吐槽的部份,我們就把唯一的粗體字拉出來討論好了:

We are excited to integrate Keybase’s team into the Zoom family to help us build end-to-end encryption that can reach current Zoom scalability.

先不講先前被戳破根本就不是 end-to-end encryption 的問題,影音上面因為 transcoding 的問題,如果要在 video stream 上做 end-to-end encryption 的話分成兩種方式可以做:

a) 一種是發送端直接產生出多個不同 bitrate 的 video stream,這種方式其他家都已經很熟悉了,缺點也很明顯,就是吃各種資源,包括發送端的壓縮能力與頻寬。

b) 另外一種方式是產生出可以疊加的 video stream,有點像是 progressive image 的方式,第一個 stream1 的畫質最低,第二個 stream2 則是「補強」第一個 stream1,這樣子可以降低資源的需求。

另外有想到 Homomorphic encryption 的方式,直接可以疊加加密後的 stream1 + stream2,不過 bitrate 應該不會降低,就算真的設計的出來應該也沒用...

如果是 a) 的方式,業界對於 key 的交換都已經解的還不錯了,但這個方式沒什麼競爭性 (因為其他家也都已經做完了)。

如果是 b) 的方式,很明顯該找的是 codec 的公司 (要做出可以疊加的 codec),而不是搞密碼學的公司。

回到原來的問題,現有的團隊有 2500 人,裡面的技術團隊沒辦法搞定 end-to-end encryption,ok 沒關係,那現在的 CTO Brendan Ittelson 應該可以建一個團隊吧?所以我翻了一下他的 LinkedIn 看了一下他的經歷,對不起我錯了,我瞬間不知道怎麼寫下去了,我豆頁痛...

透過 WebRTC 直接在網頁對傳檔案的服務

Twitter 上看到的服務 WEBWORMHOLE

透過 WebRTC 直接網頁對網頁傳資料,就不需要再透過第三方服務了。當然這樣做的前提是雙方都要在線上。

另外也可以在 cli 下面用:

之後要傳大檔案找不到空間放的時候可以用看看...

玩一下 Zipcall,走 WebRTC 與 P2P 架構的會議系統

這個連結在瀏覽器的 tab 上好幾天了,要寫這篇的時候試著找了一下當時是從哪個管道看到的來源,翻了一下看起來沒有在 Hacker News Daily 上面列出,但在 Hacker News 上面有找到討論串,不過最近沒有去從那邊翻連結...

Anyway,Zipcall 是使用 WebRTC 實做出來的會議系統,會議相關的流量會直接透過點對點的架構傳輸,不需要透過 server 交換。

由於架構上沒有 server 幫忙重新壓縮再轉給不同的使用者,也就 client 得自己處理,對硬體要求應該會比較高,另外對頻寬的要求也比較大。

另外他提到 latency 比較低這件事情,剛剛用兩隻 webcam 測試,一個掛到 vm guest 裡面,另外一個掛在 vm host 上面,測試下來很明顯可以感覺比起之前用 Zoom 高,可能要再研究到底是什麼原因,不確定跟 vm 有沒有關係,不過還在可以接受的範圍。

安全性與隱私性的實做方式也還得再看看是怎麼弄的,不過目前看起來應該可以先拿來玩玩...

jQuery 3.5.0 的修正,補 XSS 漏洞

這次 jQuery 3.5.0 修正了一個安全性漏洞:「jQuery 3.5.0 Released!」,不過實測了一下,不完全算是 jQuery 的自己出的問題,比較像是幫使用者擦屁股。

jQuery 的說明如果看不懂,可以交叉參考「XSS Game」這篇的說明,搜尋 htmlPrefilter 應該就可以看到了。

這次修正的函數是被 html() 用到的 htmlPrefilter(),這個函數會在 3.5.0 之前會把 <tag/> 這樣的元素轉成 <tag></tag>,而 3.5.0 之後會保留本來的形式。

利用這個特性,就可以用這樣的字串來打穿 WAF:

<style><style/><script>alert(1)<\/script>

原因是 WAF 在看到時會以為 <script><style> 內部的 data 而認為不是 XSS 攻擊而穿過 WAF 的檢查,但實際上被 jQuery 展開後變成:

<style><style></style><script>alert(1)<\/script>

而最前面的 <style><style></style> 被當作是一包,後面的 <script> 就成功被拉出來執行了。

這是相同程式碼使用 jQuery 3.4.1 與 jQuery 3.5.0 的差異,我把 alert(1) 改成 document.write(1),比較容易在 JSFiddle 上看出差異:

不過回過來分析,會發現一開始用 html() 才是問題的起點,要修正問題應該要從這邊下手,而不是用 WAF 擋...

處理很久前用 OpenSSL 加密的備份資料

因為想要翻一些舊的文章 (小說),想把以前 BBS 的備份拉出來看看裡面有沒有,結果發現 OpenSSL 解半天都解不開,還跑去玩了 bruteforce-salted-openssl 這個專案:

Try to find the password of a file that was encrypted with the 'openssl' command.

後來也是因為這個專案提醒,發現 openssl enc 指令在 OpenSSL 1.0.x (以及之前) 預設是用 MD5 當 digest algorithm,而 1.1.x 換成了 SHA-256,而我的備份資料應該是在 0.9.x 的年代就生出來了...

指定 -md md5 後就正常解出來了:

openssl enc -bf -d -md md5 -in ooxx.tar.gz.bf -out ooxx.tar.gz

另外一個收穫是 CPU 溫度降了不少:因為跑 bruteforce-salted-openssl 的時候 CPU 到 80 度,感覺撞到安全值卡在 4.0Ghz,所以就把 CPU 電壓降了 0.1V,看起來溫度低了不少 (少了五度),但跑起來還是 4.0Ghz...

Cloudflare 改用自己的 CAPTCHA 服務 hCaptcha

CloudflareGooglereCAPTCHA 改用自家的 hCaptcha:「Moving from reCAPTCHA to hCaptcha」。

看起來其實就是錢的問題,reCAPTCHA 要收費了,而以 Cloudflare 的量會太貴:

Earlier this year, Google informed us that they were going to begin charging for reCAPTCHA. That is entirely within their right. Cloudflare, given our volume, no doubt imposed significant costs on the reCAPTCHA service, even for Google.

另外 hCaptcha 有提供免費版本給一般網站用,剛出來這幾天等白老鼠寫心得後,再決定要不要跳進去測試...

OpenSSH 的三個進階用法:CA 架構、透過 Jump Server 連線、2FA

在「How to SSH Properly」這篇裡面講了三個 OpenSSH 的進階用法:CA 架構、透過 Jump Server 連線,以及 2FA 的設定。

之前蠻常看到使用 -o StrictHostKeyChecking=off 關閉檢查,但 OpenSSH 有支援 CA 架構,可以先產生出 Root CA,然後對 Host 的 Public Key 簽名,在連線的時候就可以確保連線沒有被調包 (通常是 MITM),但得設計一套機制,自動化機器生出來後的步驟。

另外一個可能的方式是 SSHFP,搭配 DNSSEC 也可以確認連線沒有被調包,不過這又牽扯到 DNS 的部份...

第二個提到的是 Jump Server (Bastion host),之前的作法是用 -A 把 authentication agent 帶過去再連進去,這邊則是教你怎麼下指令直接連線,而不需要先連到 Jump Server (但實際上底層是透過 Jump Server)。

第三個是 2FA,對於還是使用密碼登入的系統可以多一層保護。文章裡面講的是 TOTP 的方式 (就是現在還蠻常見的 app + 六碼動態數字)。

先知道有這些東西,之後真的有用到的場景時再回來看...