Tor 0.4.7.7 支援 congestion control

Tor 首度在協定內支援了 congestion control:「Congestion Control Arrives in Tor 0.4.7-stable!」。

這個新功能會帶來效能的提昇:

Tor has released 0.4.7.7, the first stable Tor release with support for congestion control. Congestion control will eliminate the speed limit of current Tor, as well as reduce latency by minimizing queue lengths at relays. It will result in significant performance improvements in Tor, as well as increased utilization of our network capacity.

之所以沒有辦法直接利用 packet loss 的方式讓 TCP network stack 直接判斷 congestion control,是因為這樣會產生 side channel:

Crucially, we rejected mechanisms to provide congestion control by allowing packet drops, due to the ability to introduce end-to-end side channels in the packet drop pattern.

所以 Tor 得自己實做 congestion control 演算法,選擇的演算法是結合了 Vegas 的 Tor-Vegas,可以看到在實驗中,德國與香港的 exit node 效率大幅提昇:

另外也因為 0.4.7.7 也出來一個禮拜了,也可以看到 Advertised Bandwidth (算是 Tor network 觀察到的 bandwidth) 開始成長:

另外一個重要的點是 UDP 的支援計畫,看起來在這次改善後也比較有可行性了:

The astute reader will note that we rejected datagram transports. However, this does not mean that Tor will never carry UDP traffic. On the contrary, congestion control deployment means that queue delay and latency will be much more stable and predictable. This will enable us to carry UDP without packet drops in the network, and only drop UDP at the edges, when the congestion window becomes full. We are hopeful that this new behavior will match what existing UDP protocols expect, allowing their use over Tor.

GitHub 將在 2023 年底強制所有使用者都啟用 2FA

GitHub 公佈了強制使用 2FA 的計畫:「Software security starts with the developer: Securing developer accounts with 2FA」。

文章副標題把該講的都講完了:

GitHub will require all users who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA) by the end of 2023.

自己開是一件事情,整個服務強制啟用是另外一個等級,還有一年多的時間...

SHA-1 在 2022 的破解速度已經降到 ~5.4 GPU years

前幾天在 Hacker News 上看到目前撞 SHA-1 collision 的難度:「How easy is it in 2022 to find a SHA1 collision? (stackexchange.com)」,原文在「How easy is it in 2022 to find a SHA1 collision?」。

在答案裡面有提到,即使在不考慮 ASIC 的情況下,光是用 GPU 算就可以可以降到 ~5.4 GPU years 了:

Remarkably, we can see that in only 5 years, we're down from an attack costing ~110 GPU years to an attack costing ~8 GPU-years in 2020 (thanks to theoretical improvements & newer GPUs) to just ~5.4 GPU years nowadays (thanks to newer, faster GPUs).

除了演算法本身的進步以外,GPU 的效能進展也帶動不少,而如果考慮到 ASIC 的話會快更多,對美國政府來說,如果搬出超級電腦來算的話,就是一天可以撞一個出來:

In a more realistic way, it would take less than a day to do it on a super-computer such as the one owned by the US Department of Energy's Oak Ridge National Laboratory (ORNL) named "Summit".

沒有在追進度,發現進展蠻快的,現在的攻擊速度比想像中快不少...

處理 EasyPrivacy 讓 bookwalker.com.tw 無法購買書籍的問題

有時候在 www.bookwalker.com.tw 上面買書會出現地區問題:

先講解法再講找問題的過程以及解釋原因好了,把這行白名單設定加進 uBlock Origin 的 My filters 列表裡面就可以了:

@@||www.cloudflare.com/cdn-cgi/trace$xhr,domain=www.bookwalker.com.tw

應該有些人看到上面敘述的問題,以及白名單的設法,就大概知道發生什麼事情了,不過這邊還是會從頭說明除錯的過程。

我一開始先確認在無痕模式下是可以看到的 (也就是在沒有延伸套件的情況下),如果是這類 case,最常見的就是延伸套件的鍋,所以接下來研究是哪個套件造成的;然後透過經驗,從容易中獎的套件開始關,一路抓下來就可以抓到是 uBlock Origin。

然後把 uBlock Origin 裡面的 Filter lists 裡面開始關,一路關就可以測出來是 EasyPrivacy 這組造成的。

然後就是拉 uBlock Origin 提供的 Logger 去看 EasyPrivacy 擋了什麼,可以看到有這條:

||cloudflare.com/cdn-cgi/trace$3p,domain=~isbgpsafeyet.com|~wyndhamdestinations.com

而熟知 Cloudflare 的人應該就知道,在 https://www.cloudflare.com/cdn-cgi/trace 裡面有 geolocation 資訊,這樣看起來應該是被 bookwalker.com.tw 拿來跑地區資訊 XD

有興趣的也可以自己跑 curl -v https://www.cloudflare.com/cdn-cgi/trace 看傳回結果。

不過這個部份居然做在前端 javascript,看起來... 好像... 可以...?

Ptt 正式關閉 Telnet 協定

在「[公告] Ptt 即日起關閉無加密的 telnet 連線方式」這邊看到正妹站長公佈關閉 Telnet 協定了,所以目前應該只剩下 WebSocketSSH 了,兩個都有走加密協定...

偶而還是會拿 Telnet 來用,像是測試 SMTP server 的時候,而 SMTP 也是少數現在大家頭痛的協定 XDDD

銀河的歷史又翻過了一頁...

OpenSSH 9.0 的 scp 與 sntrup761x25519 (Streamlined NTRU Prime)

OpenSSH 9.0 發行了,從 release-9.0 這邊可以看到重點,首先是 scp 的底層換掉,改用 SFTP 了,這點在先前「OpenSSH 的 scp 改用 SFTP 協定」這邊也有提到過:

This release switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default.

另外一個是將 OpenSSH 8.9 引入的 post-quantum cipher 放入 default:

ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default ("sntrup761x25519-sha512@openssh.com"). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo.

We are making this change now (i.e. ahead of cryptographically-relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available.

查了一下 Streamlined NTRU Prime 發現有 djb 參與,而且發現頭銜上面有掛中研院:

Daniel J. Bernstein, University of Illinois at Chicago, USA, and Ruhr University Bochum, Germany, and Academia Sinica, Taiwan

清單裡面有不少中研院的人:

Ming-Shing Chen, Academia Sinica, Taiwan

Bo-Yuan Peng, National Taiwan University and Academia Sinica, Taiwan

裡面還看到魯教授

Bo-Yin Yang, Academia Sinica, Taiwan

後面也有看到計畫相關的資訊:

Taiwanese authors were supported by Taiwan Ministry of Science and Technology Grants 108-2221-E-001-008 and 109-2221-E-001-009-MY3, Sinica Investigator Award AS-IA-109-M01, Executive Yuan Data Safety and Talent Cultivation Project (AS-KPQ-109-DSTCP).

用 objdump 學到的一些東西...

Hacker News 首頁上看到「Hand-optimizing the TCC code generator (briancallahan.net)」這則,原始文章在「Hand-optimizing the TCC code generator」這邊。

主要是在文章內看到 objdump 這個東西,作者用這兩個指令看組語:

tcc -c true.c
objdump -d true.o

另外同樣道理也可以用 gcc -c true.cGCC 轉出來的版本。

倒出來的組語是 AT&T 語法,但我熟悉的是 Intel 語法,對我的直覺上需要習慣... 另外我看了一下 GCC 編出來的組語:

0000000000000000 <main>:
   0:   f3 0f 1e fa             endbr64 
   4:   55                      push   %rbp
   5:   48 89 e5                mov    %rsp,%rbp
   8:   b8 00 00 00 00          mov    $0x0,%eax
   d:   5d                      pop    %rbp
   e:   c3                      retq

第一行的那個 endbr64 指令沒看過,查一下發現原來是 Intel 在 CPU 層設計出來的安全機制,標示這個地方可以被 indirect call 進來:「What does the endbr64 instruction actually do?」。

至於文章裡面主要提到的 mov $0x0, %eax 可以用 xor %eax, %eax 代替 (或是 sub %eax, %eax) 算是很久前就會的東西了...

可以看 Chrome Extension 程式碼的 Chrome extension source viewer

好像沒有提過「Chrome extension source viewer」這個套件,來介紹一下...

這個套件可以在尚未安裝前看 Chrome Web Store 裡 extension 的原始程式碼,算是可以在安裝前看一下 extension 在幹什麼。

以前還會遇到會 obfuscated code,導致很難看出來在幹什麼,但在 2018 年以後 Google 公告直接禁止這類行為,就不太會遇到這種情況了 (除非是很舊的 extension):「Trustworthy Chrome Extensions, by default」。

先前跟 Brave 還會打架,不過後來看起來沒這個問題了...

AWS 將會把超過兩年的 EC2 AMI 自動設為 Deprecated

AWS 的公告,超過兩年的 EC2 AMIs (Amazon Machine Images) 將會被標為 deprecated:「Amazon EC2 now reduces visibility of public Amazon Machine Images (AMIs) older than two years」。

標成 deprecated 後主要的差異會是在 DescribeImages 這隻 API 上,除了 image 的擁有人外,其他人都不會顯示出來:

Once an AMI is deprecated, it will no longer appear in DescribeImages API calls for users that aren’t the owner of the AMI.

不過知道 AMI 的 id 還是可以直接開:

Users of a deprecated AMI can continue to launch instances and describe the deprecated AMI using its ID.

沒有特地說明原因,但應該是考慮到安全性,這年頭超過兩年不更新的系統大概都有一堆洞?不過馬上就想到 OpenBSD 好像未必...