2024年10月14日~2024年10月20日に読んだ中で気になったニュースとメモ書きです。
[WeChatのMMTLSの脆弱性]
こちらのツイートから。
💬NEW REPORT: The Citizen Lab takes a deep dive into the network encryption protocol used by #WeChat, an app with over one billion users. The app uses a custom #encryption protocol called “MMTLS” that introduces cryptographic weaknesses. Read the report: https://t.co/9EmcuMXqnC
— The Citizen Lab (@citizenlab) 2024年10月15日
リンク先はこちら。
WeChatではMMTLSというTLS1.3の修正版のプロトコルが利用されているが、多くの変更によって、初期化ベクトルが決定論的であったり、前方秘匿性がない状態だったりと、脆弱性が存在しているという。
MMはMicroMessengerの略で、WeChatの中国名「微信」を英訳したものらしい。
MMTLSのClientHelloは16 f1 04...というバイト列で始まる。TLS1.3の場合は16 03 01...となっていて、03 01がTLSのバージョンを表しているので、MMTLSの場合は何か独自のバージョンのようなものを持っていると思われる。
MMTLSの実装自体は、TLS1.3と並行して行われていたようで、2017年のドキュメントが公開されている。元記事によると、TLS1.3ではまだ0-RTTが実装されるかどうかわからなかったので、WeChatに最適化するために独自のプロトコルであるMMTLSを採用したとのこと。
MMTLSでのプロトコルレベルでの暗号化以外にも、通信の前にデータのビジネスレベルでの暗号化が行われており、そちらにも色々と問題があるらしい...。
GitHubにあるレポートによると、WeChatはJavaで実装されているとのこと。
この手のプライバシーに関わる問題は中国製のアプリだとよくあるらしい。Baiduブラウザとか...。
[その他のニュース]
▼Sectigoの証明書有効期限短縮支持
こちらのツイートから。
【自分用メモ】Apple follows Google in shortening digital certificate lifespans | Sectigo® Official https://t.co/gl5pipezLS
— Yasuhiro Morishita (@OrangeMorishita) 2024年10月16日
(DeepL、一部改)
— Yasuhiro Morishita (@OrangeMorishita) 2024年10月16日
「Sectigoは、ブラウザーのこれらのイニシアチブを全面的にサポートします。この最新の投票提案のスポンサーになることを決定したことは、WebPKIエコシステムの完全性と顧客のセキュリティに対する私たちの献身の証です。」
CA/Browser ForumのBallotにはレビュワーが必要ですが、今回のClint Wilson氏(Apple)の提案のレビュワーはAndy Warner氏(Google)とMartijn Katerbarg氏(Sectigo)でした。
— Yasuhiro Morishita (@OrangeMorishita) 2024年10月16日
Sectigo公式ブログのこの記述は、この件なのかなと。
リンク先はこちら。
先週のトップニュースの続き。ブラウザベンダだけでなく、認証局側もこの動きを支持している模様。 Sectigo Certificate Managerとかで自動化できるから、ビジネスチャンスではあるんだろう。
ACMEやらなきゃな...。
▼Firefox nightlyのCT強制使用モード
こちらのツイートから。
Firefox browser testing support for #TLS #certificatetransparency https://t.co/rflgzZvfGv
— Cryptoki (@Cryptoki) 2024年10月16日
リンク先はこちら。
CTの利用を強制するモードがFirefox nightlyに実装された。そういえばChromeはCT必須だけど、Firefoxは違うんだった...。
Firefox nightlyがChromeに追いつこうと頑張っている話は以前も書いた通り。
▼Route 53 ResolverエンドポイントがSNI検証DoHサポート
こちらの記事から。
DoH自体は2023年末から利用できていたが、SNI検証を利用したDoHはサポートされていなかったらしい。アメリカのコンプライアンス要件で必要らしいけど、大変そう...。
▼中国の量子コンピュータD-Waveによる暗号への攻撃
こちらのツイートから。
Should be obvious, but since people like to amplify crap like this: Completely false. Even the Chinese newspaper source doesn't claim that they actually broke anything. https://t.co/FvPMRaQhlc
— mjos\dwez (@mjos_crypto) 2024年10月13日
リンク先はこちら。
AESなどの基礎になっているSPN構造アルゴリズムに対する量子攻撃に成功したとの報道。これが洗練されていくとAESが破られる日が来るのだろうか...。
ただ、D-Wave BOXというのは実際の量子コンピュータではない、という指摘も?よくわからない...。
Yeah the LOL part is that it's not actual QC at all, nor Chinese, but some sanction-busting D-Wave box. Sounds like it's again someone hoping that their system would magically converge on secret keys because of "quantum."
— mjos\dwez (@mjos_crypto) 2024年10月13日
▼BoringSSLのCA拡張サポート
こちらのツイートから。
[BoringSSL] Add the CA extension to client hello https://t.co/A1bmyOx131
— ゆき (@flano_yuki) 2024年10月14日
TLS CA拡張サポート
リンク先はこちら。
CA拡張(certificate_authorities)は認証に利用する証明書の発行元の認証局を指定するために利用される。TLS1.3を定めたRFC 8446で登場しているので、2018年からあるはずだが、使われていなかったのかしら...?
▼DTLS1.3解説
こちらのツイートから。
「DTLS」をご存知ですか?
— wolfSSL Japan @FIPS 140-3を取得しました! (@wolfSSL_Japan) 2024年10月16日
TLSをベースとして、UDPで安全な通信を実現するプロトコルです。
2022年に標準化されたDTLS 1.3とは何なのか、UDPベースのプログラムをセキュアにするにはどうするとよいのか、ぜひこちらの動画でご確認ください!https://t.co/78kgO8xZtd#DTLS #TLS #UDP #wolfSSL
リンク先はこちら。
2022年に開催されたウェビナーが紹介されていた。
Cで書かれたIoT機器のUDP通信にwolfSSLでDTLSを組み込む解説などもあって面白かった。TLSとDTLSの違いはイマイチ頭に入ってこなかったけど...。
▼AWS SDK for JavaとTLS1.3のバグ疑惑
こちらのツイートから。
AWS SDK for Javaを使ってTLS1.3で接続するとコネクションが使い回されないバグがあり、ワークアラウンドとしてTLS1.2を使うようにすれば回避できるらしい。EMRFS特有の問題なのか全体に関わる話なのかは分かってない #otfsg_tokyo
— matsuu (@matsuu) 2024年10月18日
多分こちらの資料の話?
AWS SDK for Java全体の問題だとしたら嫌だな...。
[おわりに]
技術書典17の締め切りが近い...ウッ。