幹壞事是進步最大的原動力
本來打算自己寫個程式訂閱 Certificate Transparency 的資料，結果發現 crt.sh 本身就有提供 Atom feed。
舉我的例子「crt.sh | gslin.org」來說，對應的 Atom feed 就在 https://crt.sh/atom?q=gslin.org 這邊。
不過 crt.sh 的速度不快，我在使用 Slack 內建的 /feed add 加了很多次才成功，但設定好之後放著收更新就可以了，看起來還算方便。
官方應該是可以把 feed 的筆數壓低，降低對後端 PostgreSQL 的壓力才對，像是只丟最近 30 天的量就好，現在看起來是所有的 entry 都轉成 Atom feed 丟出來...
AWS 的 ALB 宣佈支援 TLS 1.3：「Application Load Balancer now supports TLS 1.3」。
本來以為早就支援了，翻了一下發現應該是太多產品線的關係搞混了：
ALB 則是到了 2023 才支援 TLS 1.3...
Tailscale 也推出了類似 Cloudflare Tunnel 的產品，叫做 Tailscale Funnel：「Introducing Tailscale Funnel」。
都是透過 server 本身主動連到 Cloudflare 或是 Tailscale 的伺服器上，接著外部的 request 就可以繞進來了。
不過 Tailscale Funnel 的定位跟 Cloudflare Tunnel 有些差異，看起來 Tailscale Funnel 比較偏向給 dev/stage 環境的用法，Cloudflare Tunnel 像是要跑在 production 的設計？
目前是 alpha 階段，有些限制，像是目前能開的 port：
The ports you can specify to expose your servers on are currently to 443, 8443 and 10000.
另外從技術面上看起來一定得用 TLS 連線，因為他得透過 TLS 的 SNI 資訊來決定是誰：
We can only see the source IP and port, the SNI name, and the number of bytes passing through.
對於已經有用 Tailscale 的使用者來說好像可以玩看看，但另外一點是 Cloudflare 的機房密度很高，這點可能是 Tailscale 也要想一下的問題？
看到 CloudFront 宣佈支援帶入 JA3 資訊了：「Amazon CloudFront now supports JA3 fingerprint headers」：
Details: Amazon CloudFront now supports Cloudfront-viewer-ja3-fingerprint headers, enabling customers to access incoming viewer requests’ JA3 fingerprints. Customers can use the JA3 fingerprints to implement custom logic to block malicious clients or allow requests from expected clients only.
JA3 的頁面上可以看到說明，針對 SSL/TLS 這個複雜的 handshake 過程中，就可以從中得知不同的 client 實做，比起容易偽造的 User-agent 有效：
JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.
像是 Tor 的 SSL/TLS 連線就會有對應的 fingerprint 可以偵測：
JA3 fingerprint for the standard Tor client:
e7d705a3286e19ea42f587b344ee6865
先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」裡面提到的 curl-impersonate 就是反制這類偵測的方式。
看到「curl's TLS fingerprint」這篇，cURL 的作者 Daniel Stenberg 提到 TLS fingerprint。
先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」與「curl 的 TLS fingerprint 偽裝專案 curl-impersonate 支援 Chrome 了」這邊有提到 curl-impersonate 這個專案，試著在 cURL 裡模擬市面上常見的瀏覽器的 TLS fingerprint。
在 Daniel Stenberg 的文章裡面也有提到這件事情，另外也提到了對 curl-impersonate 的態度：
I cannot say right now if any of the changes done for curl-impersonate will get merged into the upstream curl project, but it will also depend on what users want and how the use of TLS fingerprinting spread or changes going forward.
看起來短期內他是沒打算整，跟當初 curl-impersonate 的預期差不多...
在「Let's Encrypt’s subscriber agreement changes on Sept 21 (letsencrypt.org)」這邊看到的，Let's Encrypt 有提供 diff 的內容，在「LE-SA-v1.2-v1.3-diff.docx」這邊，你也可以用 Google Docs Viewer 看：「LE-SA-v1.2-v1.3-diff.docx」。
看起來主要是用語上的改變 (可能是律師的建議？)，除了 revoke 的章節外看起來沒什麼大變化。而 revoke 的章節部份增加了這兩段文字：
You warrant to ISRG and the public-at-large, and You agree, that before providing a reason for revoking Your Certificate, you will have reviewed the revocation guidelines found in the “Revoking Certificates” section of the Let’s Encrypt documentation available at https://letsencrypt.org/docs/ , and that you will provide Your corresponding revocation reason code with awareness of such guidelines.
You acknowledge and accept that ISRG may modify any revocation reason code provided by You if ISRG determines, in its sole discretion, that a different reason code for revocation is more appropriate or is required by industry standards.
不確定自動化的 client 需不需要重新再 accept 一次？
AWS 宣佈了 API 的 TLS 1.0/1.1 日落期：「TLS 1.2 to become the minimum TLS protocol level for all AWS API endpoints」。
公告裡提到是 2023/06/28：
This update means you will no longer be able to use TLS versions 1.0 and 1.1 with all AWS APIs in all AWS Regions by June 28, 2023.
TLS 1.0 目前還堪用的應該是 AES + CBC 類的 cipher，在正確實做 mitigation 下加減可以用：
對於像是 Java 6 環境這類很老舊的系統，如果真的無法升級的話，可以想到 workaround 的方法是透過 self-signed CA + TLS proxy 來幫忙把 TLS 1.0 的連線請求解開，重包成 TLS 1.2 的連線。
在 Hacker News 上看到「Decrypting your own HTTPS traffic with Wireshark」這篇，就是用 SSLKEYLOGFILE 請 library 把 TLS 相關的 key 與 random number 寫到檔案裡面讓 Wireshark 可以解讀拿來用。對應的討論在「Decrypting your own HTTPS traffic with Wireshark (trickster.dev)」這邊。
看起 OpenSSL 系列的 library 都有支援這個變數，另外 NSS 也支援這個變數，所以常見的程式應該都包含在內了...
比起 MITMA 類的方式 (像是 mitmproxy)，這個方式會更接近真實的情境，不另外產生 CA 與 key，不過缺點就是使用的情境就再受限一些，算是除了 MITMA 類方式的另外一個方案...
AWS 宣佈 AWS KMS 與 AWS ACM 支援 post-quantum TLS ciphers：「AWS KMS and ACM now support the latest hybrid post-quantum TLS ciphers」。
全區支援 Kyber、BIKE 與 SIKE 這三個演算法：
The three PQC key encapsulation mechanisms (KEMs) offered are Kyber, BIKE, and SIKE. Hybrid post-quantum TLS combines a classical key agreement, such as ECDHE, with one of these KEMs. The result is that your TLS connections inherit the security properties of both the classical and post-quantum key exchanges.
Hybrid post-quantum TLS for AWS KMS and ACM is available in all public AWS Regions.
不過這是 NIST Post-Quantum Cryptography Standardization 裡 Round 3 裡面其中幾個演算法而已：
AWS Key Management Service (KMS) and AWS Certificate Manager (ACM) now support hybrid post-quantum key establishment for transport layer security (SSL/TLS) connections using the latest post-quantum ciphers from Round 3 of the NIST Post-Quantum Cryptography (PQC) selection process.
順便補一下隔壁棚 Cloudflare 的研究：「Making protocols post-quantum」。
先前在「修正 Curl 的 TLS handshake，避開 bot 偵測機制」這邊提到 curl-impersonate 這個專案，試著修改 curl 的 TLS handshake fingerprint 讓偽裝的更好，本來只支援 Firefox，現在則是支援 Google Chrome 的 fingerprint 了...
作者寫的兩篇說明文章也可以看看：「Making curl impersonate Firefox」、「Impersonating Chrome, too」。
看起來愈來愈完整了，連 LD_PRELOAD 的用法也出現了，然後在 Arch Linux 上也出現 AUR 可以用了...