2026年4月27日〜2026年5月3日に読んだ中で気になったニュースとメモ書きです。
[ECHConfigの問題]
こちらのツイートから。
Every lock needs a key. The hard part is not always designing the lock. Sometimes it is getting the key to the person who needs it.
— Nick Sullivan (@grittygrease) 2026年4月28日
That is the problem I address in the third post of my CDT series on Encrypted Client Hello. ECH is designed to close one of the last major metadata…
リンク先はこちら。
ECH（Encrypted Client Hello）についての連載の第3回。仕組み（暗号）はだいたい固まったけれど、クライアントが暗号化に使う鍵（ECHConfig）をどう届けるかがまだ難しい、という話。今はDNSがECHConfigの配布と認証を担当しているが、そこがGreat Firewallのような検閲環境だと攻撃対象になる、と。
代替案としては、配布と認証を分離してwell-known endpoint、key transparencyなどの手法で配布を行い、ECHConfig自体に署名をすることで認証を実現できる、とのこと。
結局well-known endpointだと検閲される気もするけど、どうなんだろう？key transparencyはMerkle Treeを使って鍵の正当性を示すらしいけど、結局届かなかったら意味がないような...。
Cryptography & Security Newsletterでも同じタイミングでこちらの記事が取り上げられていた。
[Cryptography & Security Newsletter #136]
こちらのツイートから。
Cryptography & Security Newsletter is out! In this issue:
— Feisty Duck (@feistyduck) 2026年4月30日
- ECH Is Done, But Can We Make It Work?
- PQC, Cryptography, Privacy, PKI and more! https://t.co/iFsiKBHuny pic.twitter.com/vVmYudcA4v
リンク先はこちら。
トップニュースはECHの件。
実装はできたが、運用にはまだ課題がありそう。そもそもcloudflare-ech.comしかECHをサポートしていないので、ブロックも用意、と...。
気になったショートニュースは以下。
- ML-KEM/ML-DSAの実装をテストするフレームワークcrucible
- X25519とML-KEM-768のどちらが先に破られるかの賭け
- 9つのプロトコルでのPQC移行状況
- 2026年第1四半期のrustlsベンチマーク
- FBIがSignalのメッセージを通知データベースから復元
- Let's EncryptのTLS証明書テストサイト
- CTログの負荷分散状況
- DigiCertのMTC Playground（ML-DSAも）
- Firefox 150がQWAC証明書インジケータを実装
- QWAC認証局の一部しか主要ブラウザのルートストアでサポートされていない問題
[その他のニュース]
▼しゃぶ葉のテーブルで学ぶ MITM
こちらのツイートから。
着眼点がいいなと思い開いてみたら企業ブログなのでビビった(中身はまともでした)https://t.co/Tx7TX1Upi0
— sat (@satoru_takeuchi) 2026年4月28日
リンク先はこちら。
キッチン＝サーバ、客席＝クライアント、皿＝パケット、豚肉＝ペイロードという対応で MITM を解説している。六穀豚が豚バラ肉にすり替えられても気づけない（改ざん）、本物のキッチンから来たかどうかが分からない（なりすまし）、をいかに防ぐか...。
スマホアプリの診断のためにルート証明書をインストールしてもAndroidはデフォルトで信頼しないので大変という話は知らなかった。
▼SplitSSHell（CVE-2026-35414）
こちらのツイートから。
OpenSSHにrootシェルが取れる15年物の脆弱性。CVE-2026-35414はCVSSスコア8.1で、カンマ文字をCAが使用するシナリオでのauthorized_keysの不適切な取扱。カンマがリストの分割文字として扱われてしまうバグ。"deploy,root"といったプリンシパル宛の証明書で遊べる。 https://t.co/w38DVMCdYY
— kokumօtօ (@__kokumoto) 2026年4月28日
リンク先はこちら。
「SplitSSHell」と名付けてられた、過去 15 年分のOpenSSHに存在していた脆弱性。本来は 1 つの文字列として扱うべきcertificate principalを、暗号スイートと鍵交換のリストネゴシエーション処理から流用した関数がカンマで split してしまい、片方の断片がプリンシパル名と一致するだけで認証成立してしまう、という実装ミス。
▼Baseline RequirementsにML-DSA許可
こちらのプルリクエストから。
CA/Browser ForumののBaseline Requirementsに対して、Google Trust Servicesの e3n0 氏（Ethan Davis）が出したPR。現状BRではRSAまたはECDSAしか認めていないが、ML-DSAの鍵と署名を証明書およびCA鍵ペアの両方で許容する内容。
[おわりに]
技術書典21どうしようかな〜。
