Category: Security

scp -3：直接對兩個 remote host 複製檔案

剛剛找資料才發現的，scp 指令早就可以針對兩個遠端複製檔案了：「scp from one remote server to another remote server」。

可以加上 -3，像是這樣：

scp -3 src:/foo/bar/a.zip dst:/tmp/

不過依照說明可以不用加，因為這是 default 值：

Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. Note that, when using the legacy SCP protocol (via the -O flag), this option selects batch mode for the second host as scp cannot ask for passwords or passphrases for both hosts. This mode is the default.

看了 Stack Exchange 上的回答日期，是 2014 年十月回的，所以至少 Ubuntu 16.04 就有這個功能了？(沒有去查這個功能多早...)

之前一直都是查怎麼用 rsync 搬，然後發現做不到所以都還是傻傻的透過 jump server 轉運檔案，沒想到隔壁棚早就給了解法...

這樣有些情境搬檔案就簡單多了...

Linux Kernel 後續的 LTS 版本將縮短成兩年

在「Long-term support for Linux kernel to be cut as maintainence remains under strain」這邊看到 Linux Kernel 後續的 LTS 版本將縮短成兩年的消息：

Here's one major change coming down the road: Long-term support (LTS) for Linux kernels is being reduced from six to two years.

主要的原因是舊版用的人並不多：

Why? Simple, Corbet explained: "There's really no point to maintaining it for that long because people are not using them." I agree. While I'm sure someone out there is still running 4.14 in a production Linux system, there can't be many of them.

而目前的 LTS kernel 還是會走完本來計畫的時間，4.14、4.19、5.4 以及 5.10 從表上看都是六年，5.15 是五年，最新的 LTS 6.1 則是四年。

降到兩年的話，代表各家 Linux distribution 在 LTS kernel 跑完生命週期後就得自己維護安全性更新了，或是直接升級到另外一個 kernel 版本 (後者的方法風險高一點，不確定系統的相容性)。

看起來 5.10 與 6.1 會跑很久了，都到 2026 年十二月...

Cavium (被 Marvell 併購) 在 Snowden leak 中被列為 SIGINT "enabled" vendor

標題可能會有點難懂，比較簡單的意思就是在 Snowden 當年 (2013) 洩漏的資料裡面發現了不太妙的東西，發現 Cavium (現在的 Marvell) 的 CPU 有可能被埋入後門，而他們家的產品被一堆廠商提供的「資安產品」使用。

出自 X (Twitter) 上面提到的：

這段出可以從 2022 年的「Communication in a world of pervasive surveillance」這份文件裡面找到，就在他寫的 page 71 (PDF 的 page 90) 的 note 21：

While working on documents in the Snowden archive the thesis author learned that an American fabless semiconductor CPU vendor named Cavium is listed as a successful SIGINT "enabled" CPU vendor. By chance this was the same CPU present in the thesis author’s Internet router (UniFi USG3). The entire Snowden archive should be open for academic researchers to better understand more of the history of such behavior.

Ubiquiti 直接中槍...

而另一方面，在 Hacker News 上的討論「Snowden leak: Cavium networking hardware may contain NSA backdoor (twitter.com/matthew_d_green)」就讓人頭更痛了，像是當初 Cavium 就有發過新聞稿提到他們是 AWS CloudHSM 的供應商：「Cavium's LiquidSecurity® HSM Enables Hybrid Cloud Users to Synchronize Keys Between AWS CloudHSM and Private Clouds」。

而使用者也確認有從 log 裡面看到看到 Cavium 的記錄：

Ayup. We use AWS CloudHSM to hold our private signing keys for deploying field upgrades to our hardware. And when we break the CI scripts I see Cavium in the AWS logs.

Now I gotta take this to our security team and figure out what to do.

居然是 CloudHSM 這種在架構上幾乎是放在 root of trust 上的東西...

OpenSSL 1.1.1 EoL

看到 OpenSSL 官方的公告，1.1.1 版 EoL：「OpenSSL 1.1.1 End of Life」(btw，我不知道他們為什麼網址上會放兩個 /blog/...)。

OpenSSL 1.x 與 3.x 最大的差異就是他的 license 了，1.x 版是 dual license，但這兩個 license 都與 GPL 不相容：

OpenSSL was dual-licensed under the OpenSSL License and the SSLeay License, which means that the terms of either licenses can be used. The OpenSSL License is Apache License 1.0 and SSLeay License bears some similarity to a 4-clause BSD License.

As the OpenSSL License was Apache License 1.0, but not Apache License 2.0, it requires the phrase "this product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit" to appear in advertising material and any redistributions (Sections 3 and 6 of the OpenSSL License). Due to this restriction, the OpenSSL License and the Apache License 1.0 are incompatible with the GNU GPL.

後續 3.x 的版本則改成 Apache License 2.0 了：

OpenSSL announced in August 2015 that it would require most contributors to sign a Contributor License Agreement (CLA), and that OpenSSL would eventually be relicensed under the terms of Apache License 2.0.

不過 Apache License 2.0 與 GPLv2 還是不相容 (但相容於 GPLv3)，這個更換只是換成一個比較常見的 license：

The Free Software Foundation considers all versions of the Apache License to be incompatible with the previous GPL versions 1 and 2.

話說 Ubuntu 20.04 內的 OpenSSL 是 1.1.1f，看起來光是標準的 LTS (到 2025/04) 期間都得自己維護了？其他作業系統應該也會有類似的問題...

OpenSSH 加入了 noise (keystroke timing obfuscation) 功能

在 Hacker News 上看到在 OpenSSH 裡加入 keystroke timing obfuscation 的功能：「Keystroke timing obfuscation added to ssh(1) (undeadly.org)」。

如同 commit log 裡面提到的，這個功能會想要故意沒事就送一些沒用的資料 (增加一些噪音)，降低從 side channel 被判讀的資訊量：

This attempts to hide inter-keystroke timings by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent. It also sends fake "chaff" keystrokes for a random interval after the last real keystroke. These are controlled by a new ssh_config ObscureKeystrokeTiming keyword/

基於 OpenSSH 算是 SSH 這塊的 de-factor standard 了，接下來看其他家像是 Dropbear 會不會也實作？

Tor 的 Onion 導入防禦機制，在遭受 DoS 的時候要求用戶端執行 PoW 任務

在「Introducing Proof-of-Work Defense for Onion Services」這邊看到 0.4.8 的新機制，當 Onion 服務受到 DoS 時，會需要 client 提供 PoW 證明，有證明的會優先處理：

Tor's PoW defense is a dynamic and reactive mechanism, remaining dormant under normal use conditions to ensure a seamless user experience, but when an onion service is under stress, the mechanism will prompt incoming client connections to perform a number of successively more complex operations. The onion service will then prioritize these connections based on the effort level demonstrated by the client.

主要原因是傳統遇到 DoS 時可以透過 IP address 之類的資訊設計阻擋機制，但在 Onion 服務裡面沒有這個資訊，所以需要其他方式阻擋：

The inherent design of onion services, which prioritizes user privacy by obfuscating IP addresses, has made it vulnerable to DoS attacks and traditional IP-based rate limits have been imperfect protections in these scenarios. In need of alternative solutions, we devised a proof-of-work mechanism involving a client puzzle to thwart DoS attacks without compromising user privacy.

這個 PoW 機制的說明可以在「torspec/proposals/327-pow-over-intro.txt」這邊看到，看起來是三年前 (2020/04/02) 就提出來了，直到 0.4.8 才推出。

裡面有提到 PoW 的演算法是用 Equi-X：

For our proof-of-work function we will use the Equi-X scheme by tevador [REF_EQUIX].

看起來是個方法，而且從 cryptocurrency 後大家對 PoW 的用法愈來愈熟悉了，在這邊用還不錯...

Cloudflare 可以針對不同 Hostname 給不同的 TLS 設定了

Cloudflare 總算是提供付費方案 (包在 Advanced Certificate Manager 裡面)，可以針對不同的 hostname 給不同的 TLS 設定了：「Introducing per hostname TLS settings — security fit to your needs」。

本來的限制是整個 domain 都是一樣的 TLS 設定，這點對免費仔來說還好，但對於企業客戶來說就不太好用了。

遇到客戶端 (甚至是客戶) 是 Java 6 這種不支援 TLS 1.2 的情況 (參考「Qualys SSL Labs - Projects / User Agent Capabilities: Java 6u45」這邊)，你還是得想辦法生一組 TLS 1.0 服務出來，但整個 domain 都開又有可能會死在 PCI-DSS 之類的規範。

以前遇到的時候有兩種解法，第一種是在客戶端自己解決，像是在內網架 SSL proxy (通常會搭配 self-signed CA) 讓 Java 6 的 client 還是可以透過 TLS 1.0 通訊，但是連到 internet 上面會是比較新的 TLS 1.2 或是 TLS 1.3，這種算是比較安全的。

另外一種就是在 Cloudflare 上另外開一個 domain，這樣就可以用 TLS 1.0 半裸奔。

現在這樣等於是讓第二個方案更簡單一點，不用另外開 domain，只需要在 hostname 上設定...

Google Play 將終止對 Android 4.4 的更新

Google 宣佈從八月開始將不再更新 Android 4.4 (KitKat，KK) 的 Google Play 服務：「Google Play services discontinuing updates for KitKat (API levels 19 & 20) starting August 2023」。

Therefore, we are no longer supporting KK in future releases of Google Play services. KK devices will not receive versions of the Play Services APK beyond 23.30.99.

可以看到講的是 client 端的 apk 停止更新，服務應該還是可以用一陣子，直到 Google Play 有改動，讓舊版的 client 無法用。

Android 4.4 也是個經典的版本，當初在用 LG G2 的時候是 4.2，用了一陣子有 4.4，最後一版是 5.0，再新的版本就得刷機用第三方了。

Tails 換網域名稱，從 tails.boum.org 換到 tails.net

看到 Tails 換了一個新的網域名稱，從本來的 tails.boum.org 換到了 tails.net 上：「Welcome to tails.net!」。

看了 tails.net 的 WHOIS 可以發現這也是個老域名了，甚至比 Tails 軟體出現的 2009 年還早：

Updated Date: 2022-08-09T10:30:42
Creation Date: 2002-12-18T11:36:37
Registrar Registration Expiration Date: 2024-12-18T11:36:37

理所當然的，本來的 tails.boum.org 也還會動，目前是重導到 tails.net 上面。

然後研究了一下 boum.org 是什麼，用「site:boum.org -site:tails.boum.org」翻了一下各家搜尋引擎：「Kagi 的」、「DuckDuckGo 的」、「Google 的」。

其實還不少東西？看起來像是某個業餘團體或是組織...

另外如果是用 site:tails.boum.org 找，可以發現除了主站以外，下面其實還不少 subdomain，像是 gitlab.tails.boum.org 這樣的網域，所以應該是還有不少東西要改...

CloudFront 支援 3072 bit RSA 憑證

看到 CloudFront 支援 3072 bit RSA certificate 的消息：「Amazon CloudFront announces support for 3072-bit RSA certificates」。

2048 bit 在一般情況算是夠用，畢竟現在的紀錄也才到 829 bit (參考「RSA Factoring Challenge」)：

1024-bit RSA keys are equivalent in strength to 80-bit symmetric keys, 2048-bit RSA keys to 112-bit symmetric keys, 3072-bit RSA keys to 128-bit symmetric keys, and 15360-bit RSA keys to 256-bit symmetric keys. In 2003, RSA Security claimed that 1024-bit keys were likely to become crackable some time between 2006 and 2010, while 2048-bit keys are sufficient until 2030. As of 2020 the largest RSA key publicly known to be cracked is RSA-250 with 829 bits.

但如果哪天突然又有新的演算法出來威脅到 2048 bit 的話，會多一點緩衝的空間？