幹壞事是進步最大的原動力
在「New – AWS Support App in Slack to Manage Support Cases」這邊看到的新功能，主要是下面這張圖，看起來可以直接在 Slack 上面開 private channel 跟 AWS Support 成員討論事情：
依照說明，有 Business 以上的等級都可以用：
The AWS Support App in Slack is now available to all customers with Business, Enterprise On-ramp, or Enterprise Support at no additional charge.
雖然好像不是哪麼常跟 AWS 的人打交道，但平常先掛起來好像不錯...
除了 Hertzbleed 當初公佈時的論文與網頁外，Cloudflare 上也有一篇 Hertzbleed 的解釋：「Hertzbleed explained」。
會特別拿出來提是因為這篇是 Yingchen Wang 寫的，也就是 Hertzbleed 論文裡兩位第一作者之一 (另外一位是 Riccardo Paccagnella)，而從她的網站上也可以看到 Cloudflare intern 的資訊：
Graduate Research Intern at Cloudflare, 2022 Summer
Hertzbleed 也是一種 side-channel attack，利用 CPU 會依照電量與溫度，而動態調整頻率的特性來達到遠端攻擊，而不需要在機器旁邊有功率錶之類儀器。
傳統上針對這類執行時間的程式會用 constant-time programming 來保護，但 Hertzbleed 則是利用了 CPU 會動態調整頻率的特性鑽出一個洞。現在學界對這個攻擊方式還不熟悉，等熟悉了以後應該是會把洞鑽大...
依照原理來說，定頻應該會是一個解法... 像是大家現在都很喜歡搞「降壓超頻」，算是某種定頻的方式，而一般大家會設定在全速跑也不會過熱降頻的情況。
目前 Intel 跟 AMD 都決定不 patch，依照洞一向都是愈挖愈大，來期待洞大到 RSA 或是 ECC 被打的那天...
Hacker News 首頁上看到的專案：「Libmill is a library that introduces Go-style concurrency to C.」。
使用上的設計可以看到就是用 Golang 裡面的設計，另外在網頁下方也有提到「libdill: Structured Concurrency for C」，就不是用 Golang 的設計，但是有同樣的功能性...
兩者都是 MIT/X11 license，大多數的專案用起來應該沒什麼問題，底層應該都是用 select() 或是 poll() 來實做就是了？
看到「Last remaining >1000 user community channel seized by freenode staff」這篇，freenode 把 ##linux 頻道給綁走了：
Late in the evening of June 12, 2021, freenode staff seized the largest community channel left on freenode.
新家在 Libera.Chat 上面：
Similar hostile takeovers happened to the Python community, GNU and the FSF. More than 700 FLOSS projects have abandoned freenode and now the Linux.Chat community has left as well; find our new home at #linux on Libera and our multi-platform community website here.
翻了一下「IRC Networks - Top 10 in the annual comparison」這邊的資料，看起來這個月月底有機會交叉？
另外文章裡有提到 OFTC (The Open and Free Technology Community)，看起來也是個對 open source community 開放的資源...
看到「Exploiting custom protocol handlers for cross-browser tracking in Tor, Safari, Chrome and Firefox」這個方式，跨瀏覽器收集 fingerprint 追蹤。
這次用的方式是透過 handler 追：
The scheme flooding vulnerability allows an attacker to determine which applications you have installed. In order to generate a 32-bit cross-browser device identifier, a website can test a list of 32 popular applications and check if each is installed or not. On average, the identification process takes a few seconds and works across desktop Windows, Mac and Linux operating systems.
最近大家比較常使用到的應該就是 Zoom 從網頁把應用程式帶起來的方式：
而要怎麼偵測的部份，用到了不同瀏覽器的 side channel。
Chromium 系列的部份對應的 ticket 在「Issue 1096610: External Protocol handler anti-flood protection is ineffective and flaky」這邊有被提出來。主要用到的方法是，在遇到有 handler 時，連打兩次時會被擋下：
被擋下後再打都會失敗，所以需要一個方式重設 flag，而內建的 Chrome PDF Viewer 剛好可以重設 flag：
The built-in Chrome PDF Viewer is an extension, so every time your browser opens a PDF file it resets the scheme flood protection flag. Opening a PDF file before opening a custom URL makes the exploit functional.
在 Firefox 的 side channel 則是可以透過 same-origin policy 測試當作 side channel，對應的 ticket 在「Scheme flooding technique for reliable cross-browser fingerprinting」這邊：
Every time you navigate to an unknown URL scheme, Firefox will show you an internal page with an error. This internal page has a different origin than any other website, so it is impossible to access it because of the Same-origin policy limitation. On the other hand, a known custom URL scheme will be opened as about:blank, whose origin will be accessible from the current website.
在 Safari 上的問題與 Firefox 一樣，不過沒登入看不到 ticket (也懶的註冊了)：
You are not authorized to access bug #225769. To see this bug, you must first log in to an account with the appropriate permissions.
另外，雖然 Tor Browser 底層是 Firefox，但因為有改變預設值，所以攻擊者也得換方法：
Tor Browser is based on the Firefox source code, so the Same-origin policy trick was used here as well. But because Tor Browser does not show pop-ups, we used the same-origin policy trick with iframe elements instead.
這個方法還蠻暴力的...
在大約三年前 (2018 年年初) 的時候，在讀完 Spectre 之後寫下了一些記錄：「讀書時間：Spectre 的攻擊方式」，結果在 Bruce Schneier 這邊看到消息，Google 前幾天把把 PoC 放出來了：「Exploiting Spectre Over the Internet」，在 Hacker News 上也有討論：「A Spectre proof-of-concept for a Spectre-proof web (googleblog.com)」。
首先是這個攻擊方法在目前的瀏覽器都還有用，而且包括 Apple M1 上都可以跑：
The demonstration website can leak data at a speed of 1kB/s when running on Chrome 88 on an Intel Skylake CPU. Note that the code will likely require minor modifications to apply to other CPUs or browser versions; however, in our tests the attack was successful on several other processors, including the Apple M1 ARM CPU, without any major changes.
即使目前的瀏覽器都已經把 performance.now() 改為 1ms 的精度，也還是可以達到 60 bytes/sec 的速度：
While experimenting, we also developed other PoCs with different properties. Some examples include:
- A PoC which can leak 8kB/s of data at a cost of reduced stability using performance.now() as a timer with 5μs precision.
- A PoC which leaks data at 60B/s using timers with a precision of 1ms or worse.
比較苦的消息是 Google 已經確認在軟體層沒辦法解乾淨，目前在瀏覽器上只能靠各種 isolation 降低風險，像是將不同站台跑在不同的 process 裡面：
In 2019, the team responsible for V8, Chrome’s JavaScript engine, published a blog post and whitepaper concluding that such attacks can’t be reliably mitigated at the software level. Instead, robust solutions to these issues require security boundaries in applications such as web browsers to be aligned with low-level primitives, for example process-based isolation.
Apple M1 也中這件事情讓人比較意外一點，看起來是當初開發的時候沒評估？目前傳言的 M1x 與 M2 不知道會怎樣...
在 Hacker News Daily 上看到「Visa Advertising Solutions (VAS) Opt Out (visa.com)」這篇講 Visa 的 Visa Advertising Solutions (VAS) Opt Out，本來以為是在討論企業賣資料的問題 (下面的討論的確是有在討論這個)，但最上面的討論居然是在討論 timing attack，像是這篇：
morpheuskafka 2 days ago [–]
Checked and the Mastercard one someone posted below doesn't seem to be vulnerable to this. My real card number and a dummy mastercard number with valid prefix and check digit both returned a 200 OK in around 1.01s. A random 16digit number without valid check digit returned 400 Bad Request in about 800ms. Decided to check that one since they have a completely useless machine-readable catchpa.
For Visa it was 835ms for valid, 762ms for dummy, prefix and check digit appears to be checked client side.
我印象中這類方式已經發展很久了 (透過網路反應時間的 timing attack)，討論裡面有提到「Exploiting remote timing attacks」這篇，也是十多年前的資料了... 不過官方網站玩起來總是有中特別爽的感覺 XDDD
不過 Visa 的這個網站前面用了 Cloudflare，用機器人掃感覺很容易被擋，這又是另外一回事了...
剛剛更新 Google Chrome 後發現 address bar 又被動手腳了 (我是 beta channel 的版本)，在網址列上的 Protocol (Scheme) 與 www subdomain 不見了，而本來裝 Suspicious Site Reporter 可以讓 URL bar 恢復的方式也失效了。
翻了一下老問題「Chrome address bar no longer shows protocol or www subdomain」，裡面有提到新的解法 (他寫的當下) 是「The current solution in Chrome 83+」這個，直接在網址列上選右鍵，可以看到 Always show full URLs 這個選項，這是整個 Google Chrome 的選項，而非單一站台選項，選下去後就生效了：
而本來的 Suspicious Site Reporter 也可以拔掉了 (沒有用處了)。
AWS 宣佈 t3 系列的機器也可以上 Dedicated Single-Tenant Hardware 了，也就是實體的機器不與其他人共用：「New – T3 Instances on Dedicated Single-Tenant Hardware」。
會需要避免共用實體機器，其中一種常見的是需求是 compliance，主要是在處理資料 (尤其是敏感資料) 時要求實體隔離，以降低 side-channel attack 或是類似攻擊的風險：
Our customers use Dedicated Instances to further their compliance goals (PCI, SOX, FISMA, and so forth), and also use them to run software that is subject to license or tenancy restrictions.
另外一種情境是 AWS 的美國政府區，直接與一般商業區的系統切開，不過這也得有經濟規模才有辦法這樣玩...
這幾年量子電腦的進展不斷有突破，雖然到對於攻擊現有的密碼學看起來還有一段時間，但總是得先開始研究對量子電腦有抵抗性的演算法...
其中 Google Chrome 的團隊與 Cloudflare 的團隊手上都有夠大的產品，兩個團隊合作測試的結果在學界與業界都還蠻重視的：「Real-world measurements of structured-lattices and supersingular isogenies in TLS」、「The TLS Post-Quantum Experiment」。
Google Chrome 這邊是使用了 Canary 與 Dev 兩個 channel，有控制組與兩個新的演算法：
Google Chrome installs, on Dev and Canary channels, and on all platforms except iOS, were randomly assigned to one of three groups: control (30%), CECPQ2 (30%), or CECPQ2b (30%). (A random ten percent of installs did not take part in the experiment so the numbers only add up to 90.)
這兩個演算法有優點也有缺點。一個是 key 比較小，但運算起來比較慢 (SIKE，CECPQ2b)；另外一個是 key 比較大，但是運算比較快 (HRSS，CECPQ2)：
For our experiment, we chose two algorithms: isogeny-based SIKE and lattice-based HRSS. The former has short key sizes (~330 bytes) but has a high computational cost; the latter has larger key sizes (~1100 bytes), but is a few orders of magnitude faster.
We enabled both CECPQ2 (HRSS + X25519) and CECPQ2b (SIKE/p434 + X25519) key-agreement algorithms on all TLS-terminating edge servers.
感覺還是會繼續嘗試，因為這兩個演算法的缺點都還是有點致命...