先週に続き、2022年4月18日～4月24日に読んだ中で気になったニュースとメモ書き（TLSらじお第54回 の前半用原稿）です。
- [CVE-2022-21449：サイキック・シグネチャ]
- [Google Transparency Reportサービス終了予定]
- [TLSチェックツール]
- [DTLS1.3]
- [その他のニュース]
- [まとめ]
[CVE-2022-21449：サイキック・シグネチャ]
こちらのツイートから。暗号バグ・オブ・ザ・イヤーて。
Welp. It’s the crypto bug of the year. Mark it down for April. Java 15-18 ECDSA doesn’t sanity check that the random x coordinate and signature proof are nonzero; a (0,0) signature validates any message. Breaks JWT, SAML, &c. https://t.co/t2WgnS0g3A
— Thomas H. Ptacek (@tqbf) 2022年4月20日
リンク先の記事はこちら。
年末のLog4jに始まり、Spring4Shellもあったし、Java関連の脆弱性が最近目に付く。今回のサイキック・シグネチャもJavaの脆弱性である。
Java15〜18で、ECDSAというデジタル署名の検証にバグがあり、メッセージmに対する署名値(r,s)が、本来であればそれぞれ1以上の値でなければならないところ、0で有効な署名と見做されてしまうらしい。
なぜ急にJava15からそんなバグが？と思ったら、古いネイティブコード（Cによる実装）を置き換えようとした結果、デグレードが発生したらしい。
kjurさんが色々と検証してくださっていた。
サーバー証明書に使ってみたり、クライアント認証を突破したり、他のライブラリでのJWT検証を確認したり。なるほど、JREのECDSA検証処理を使わず自前で実装してるライブラリを使ってる場合は影響がなさそう。
[速報] EC署名値をRS=0,0にいじったSSLサーバー証明書のサイトにJava SSLSocketを使ったSSLクライアントでつないでみたら普通に接続成功しちゃいましたね。
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年4月21日
[悲報] Tomcat 8.5.78+OpenJDK17.0.2でもSSLクライアント認証でECクライアント証明書の署名値をR,S=0,0に細工した証明書でクライアント認証できてしまうことを確認。はひ〜ちかれた。Tomcat嫌い！！！
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年4月21日
JavaのECDSA脆弱性の話なんだけど、BouncyCastleのプロバイダーでは、そんな馬鹿な脆弱性は置きないことが確認できた。(あたりまえだよね)
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年4月20日
Java ECDSA脆弱性の件、署名値を細工してR,S=0,0にしたJWTをJavaのJDK 17のSignatureクラスで検証したところ、やはり誤って検証成功となってしまうことを確認した。Auth0 java-jwtは何だか例外発生して検証できなかった。Auth0 ECDSAAlgorithmクラスでうまく避けられてるのかな。
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年4月22日
こちらのツイートによると、ECDSAでなく、EdDSA（エドワーズ曲線DSA）やSchnorrといった新しい署名方式を利用するとよい、とのこと。
Major bug. Yet another reason to prefer Schnorr or EdDSA over ECDSA https://t.co/WGP2PKbBAR
— Steven Galbraith (@EllipticKiwi) 2022年4月20日
Rustの暗号チームのツイートによると、RustではNonZeroScalarという型を定義することで同種のバグを防いでいるらしい。
Our `ecdsa` crate prevents vulnerabilities like Java's CVE-2022-21449 using type safety.
— Rust Crypto (@RustCryptoOrg) 2022年4月20日
We use a `NonZeroScalar` type to model the `r` and `s` components of an ECDSA signature. This prevents either of them from ever accidentally being zero.https://t.co/4fpigNWTUt pic.twitter.com/xWJB3TLjVz
日本語でも記事が出ていた。
[Google Transparency Reportサービス終了予定]
久しぶりにCT（証明書の透明性）ログを確認しようとして、Googleのサイトを表示したところ、2022年5月15日サービス終了予定と表示されていた。
Googleが証明書の透明性の維持にパワーを割かなくなる、ということではなく、画面上でログを検索できなくなるということらしい。APIとしては引き続き提供されるのだろうか。
検索できるの便利だったのにな...。5月以降はcrt.shとかを使うことになりそう。
[TLSチェックツール]
こちらのツイートから。
TLS/SSLのチェックツールであるhttps://t.co/2sCizVIkku、めっちゃ進化してた。もうQualysのSSL Server Testの代わりにhttps://t.co/2sCizVIkkuでええぞ。 / “drwetter/testssl.sh: Testing TLS/SSL encryption anywhere on any port” https://t.co/NAMj1y38b9
— matsuu初段 (@matsuu) 2022年4月20日
QualysのSSL Server Testだとサーバー側にテストした記録が残ってしまうので、コマンドラインで実行できるのは良さそう。
監視するならこちらもよろしくねhttps://t.co/kfS2QYINU2
— matsuu初段 (@matsuu) 2022年4月20日
証明書チェックのためのコマンドラインツールもあるらしい。良さげ。
[DTLS1.3]
こちらのツイートから。
RFC 9147
— ゆき (@flano_yuki) 2022年4月21日
The DTLS Protocol Version 1.3https://t.co/iyfyt6Uszs
おおーー！！DTLS1.3でた！！
TLSは2018年に1.3が出ていたけど、DTLSはまだ1.3になっていなかったようだ。
初版から数えると5年以上かかっている模様。
RFC 9147: The Datagram Transport Layer Security (DTLS) Protocol Version 1.3が発行された！
— 菅野 哲 (Satoru Kanno) (@satorukanno) 2022年4月22日
2016年10月に初版が投稿されてから長い年月をかけて発行されたので感慨深い。https://t.co/4TK59TfcM0
そういえばQUICもUDPだった気がするけど、同じUDPのDTLSとはどういう棲み分けなんだろう...。
下二桁合わせがち
— ゆき (@flano_yuki) 2022年4月23日
RFC 2246: TLS1.0
RFC 4346: TLS1.1
RFC 5246: TLS1.2
RFC 8446: TLS1.3
RFC 4347: DTLS1.0
RFC 6347: DTLS1.2
RFC 9147: DTLS1.3
QUICといえば、バイトごとに解説してくれるサイトがあるとのこと。
TLS 1.3だけではなく、QUICのもあるｗ
— 菅野 哲 (Satoru Kanno) (@satorukanno) 2022年4月23日
みんな気づかないけど日々使ってしまっているQUICだけど、実際にどんなことやってるかを知るにはいいかも？
--
The Illustrated QUIC Connection,https://t.co/l6JyRA55zf
[その他のニュース]
▼続々kTLS
こちらのツイートから。
もともとpicotls使ってるところを、がんばってkTLS対応したら速度が20%弱落ちて、えーまじかーと思ってOpenSSLと比べてみたら、OpenSSLは更に10%くらい遅かった。なんだ遅いの同士の争いか...
— Kazuho Oku (@kazuho) 2022年4月18日
perf report見ると、ktlsのソフトウェア実装は、ハードウェア実装と違ってパケット送信タイミングではなく、sendfile呼ばれたタイミングで同期的に暗号化してるんだけど、メモリ確保で11.7%CPU時間使ったりしてる pic.twitter.com/aANl3zsoUw
— Kazuho Oku (@kazuho) 2022年4月18日
まーあとaesgcm実装が理論値出てない可能性もありそう。aes 4ブロックのスティッチング&インターリーブだから、理論上いけなくはなかった気もするけど実際はgcm側が厳しいと思う。OpenSSLは6ブロック、NSSは8ブロック、picotls fusionはパケット単位でgcmの中間演算することでgcmの負荷を減らしてる
— Kazuho Oku (@kazuho) 2022年4月18日
速度のためにカーネルにオフロードしてると思ってたんだけど、意外とそうでもないらしい。ハードウェアじゃなくてソフトウェア実装だから？
▼t.coの証明書エラー
こちらのツイートから。
t. co に api.twitter. com の証明書が当たっているせいで証明書エラーになっている模様。きっと何度かリロードすると別のサーバー経由して問題発生しなくなりそうなので、残しておく。 pic.twitter.com/iHCmDrIG1w
— kaz. Suenaga / 末永 和史 (@kazSuenaga) 2022年4月19日
こういうPKI運用上のエラーは意外とよくあるみたい。先週もあったし...。
▼Firefox Telemetry
こちらのサイト。
Firefoxのbeta/nightlyバージョンに関する色々な統計データが見れるのを見つけた。SSLコネクションが利用可能になるまでのミリ秒とか、OCSPステープリングの利用回数などが見られる。
▼Bulletproof TLS and PKIの無料サンプル
こちらのツイートから。
Free Sample Chapters! If you'd like to get a better look at Bulletproof TLS and PKI before buying it, take a look at these:
— Feisty Duck (@feistyduck) 2022年4月21日
- TOC, Preface, Chapter 1 (Introduction to SSL/TLS and Cryptography), Index
- Two OpenSSL chapters called OpenSSL Cookbook
Enjoy! https://t.co/1fxAsefDa0 pic.twitter.com/xotx3Uf6Iy
『プロフェッショナルSSL/TLS』のバージョンアップ版にあたるBulletproof TLS and PKIの第1章 SSL, TLS, and Cryptographyが無料で読める。変更点も多そうなので読んでみるか...。
▼GMO代表のツイート
こちらのツイートから。
この件は、僕達の力不足です。
— 熊谷正寿【GMO】🇺🇦STOP WAR🇺🇦 (@m_kumagai) 2022年4月24日
ただ、情報セキュリティの根幹である｢SSL認証局｣を、国内で唯一GMOが所有していると言う事を、ご存知ない官僚や政治家の方も多く、驚いた事がある。
その意味では、ひろゆき君の言う通り、自国のITサービスの研究不足(=育てる気が無い）と言う側面は否めない。
続↓ https://t.co/KPtQEYgWnb
ちょっと何いってるかわからない...。こちらのツイートにもあるように他社も認証局を運営している。ロシアみたいに国営の認証局を設置せよということなのだろうか？
🧐🧐🧐🤔🤔🤔
— Anya Tokugawa /*🐧🎧 🎓 Master 2 (Informatics) */ (@anya_tokugawa) 2022年4月24日
2006/12/27 民間認証業務の現状と課題https://t.co/5c1WzBSbLh
2019/04/15 ウェブサイト認証(SSLサーバ証明書)の 現状と課題 - 総務省https://t.co/cjDtsRU6Pk pic.twitter.com/x6BHTua1Gf
