2024年6月3日～2024年6月9日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第160回分。
[TLS Key Share Prediction]
こちらのツイートから。
Defines a mechanism for servers to communicate their key share preferences via DNS to reduce TLS handshake round-trips. https://t.co/r2Q3gojO0g
— Ryan Hurst (@rmhrisk) 2024年6月4日
リンク先はこちら。
Googleの人による新しいインターネットドラフトが提案されています。TLSハンドシェイクのラウンドトリップを削減するためにDNS経由で鍵共有の設定を伝達する手法だとか。
TLS1.3のClientHelloメッセージでは、supported_groupsとkey_shareという2つのTLS拡張を利用して鍵共有のための情報を送信します。supported_groups拡張には、クライアントがサポートするアルゴリズムのことで、secp256r1やx25519といった楕円曲線のグループや、ffdhe2048やffdhe4096といった有限体のグループが含まれます。key_share拡張はTLS1.3で登場したTLS拡張です。supported_groupsのうちで、サーバーがサポートしておりハンドシェイクが成立するであろうとクライアントが想定するグループ1つ以上の、クライアントの公開鍵がkey_share拡張に含まれます*1。しかし、最終的に利用される鍵は1つなので、通常クライアントは無駄に複数の公開鍵を計算することはしません。
サーバー側はClientHelloメッセージを受け取り、key_shareで送られてきたグループでハンドシェイクできる場合は、サーバーの公開鍵をServerHelloメッセージのkey_share拡張に含めて返送します。
しかし、サーバーがサポートしているアルゴリズムがkey_shareに含まれていない場合は、ServerHelloメッセージではなくHelloRetryRequestメッセージがクライアントに送られ、ClientHelloからハンドシェイクをやり直すことになります。
このやり直しは、耐量子暗号の場合にはコストが顕著になります。特に、このドラフトで問題とされているのは、ある耐量子暗号アルゴリズムから別のアルゴリズムへの移行が行われるようなフェーズのようです。
DNSを経由してsupported_groupsの情報を伝えるのに利用されるのは、SVCBリソースレコード（Service Binding and Parameter Specification、RFC 9460）です。これは、Encrypted Client Helloで利用するための公開鍵を公開するためにも利用されるほか、TLS上でやりとりされるHTTPのバージョンなどをやりとりするためにも利用されています。既存の利用法を考えると、確かに今回提案されている使い方はアリな気がします。
[その他のニュース]
▼OpenSSLの脆弱性（CVE-2024-4741）
こちらのツイートから。
OpenSSLに任意のコード実行につながる脆弱性、注意を #MynaviNews (June 2)#脆弱性 #OpenSSL #情報セキュリティ #JPCERT #CVE2024https://t.co/qcs3I6e2oM
— キタきつね (@foxbook) 2024年6月2日
リンク先はこちら。
https://www.openssl.org/news/secadv/20240528.txt
アプリがSSL_free_buffersというAPIを直接呼び出す場合にのみ問題があるとか。TLSレコードのボディをネットワークから完全に受け取れていない場合に問題があるようです。耐量子暗号アルゴリズムでClientHelloが巨大化したことが影響したりするかも？
▼不正アクセスによるドメインハイジャック
こちらのツイートから。
怖すぎ。レジストラはどこ?>『ドメイン管理会社へ第三者が不正にアクセスを行い、海外のドメイン管理会社へのドメイン移管処理が行われる…失ったドメインが…取り戻せない可能性が高い』 / “夢展望[3185]：不正アクセスによる当社子会社公式ホームページのドメイン盗難…” https://t.co/83n34qAAEd
— 徳丸 浩 (@ockeghem) 2024年6月4日
リンク先はこちら。
こういうのがあるとCT（Certificate Transparency）が普及してて良かったな、と思います。crt.shのようなサイトを使えば、証明書が不正発行されていても気づくことができます。
レジストラの脆弱性でドメイン名ハイジャックされた過去事例で有名なものはこれですね。脆弱性悪用後の手口は違いますけど。https://t.co/yFZLFCd8VVhttps://t.co/NAtZAbPpa9https://t.co/PK5MuTXUuP
— 徳丸 浩 (@ockeghem) 2024年6月4日
▼NIST SP800-108の脆弱性
こちらのツイートから。
Attacking NIST SP 800-108 https://t.co/hNPdqCGUPa
— Frank ⚡ (@jedisct1) 2024年6月5日
リンク先はこちら。
NIST SP800-108はPRF（擬似乱数関数）を用いた鍵導出についての標準ですが、実際にこのドキュメントで提案されたAES-CMACを利用すると、最終的にえられる鍵を攻撃者がコントロールできるようです。
Dual_EC_DRBGに続くNISTの陰謀説が思い浮かびますが、ブログの筆者は否定的なようです。
▼Let's Encrypt 2024 Ceremony
こちらのツイートから。
We're switching issuance to our new intermediate certs today! If you're not sure if you might be affected, we encourage you to read our recent blog post. https://t.co/NKpP84pN2f pic.twitter.com/qxC5Ypp7t4
— Let's Encrypt (@letsencrypt) 2024年6月6日
何度か取り上げていた中間証明書の変更がついに行われるようです。
実際に切り替えられたことを確認してくれているツイートも。
Let's Encryptの中間証明書が，本日未明の2:52:13頃に切り替えられたようです． pic.twitter.com/I5JiF0Swqr
— testtlnls (@testtlnls) 2024年6月6日
新しい発行者はR10，R11，E5，E6です．（C = US, O = Let's Encrypt, CN = R11など）
— testtlnls (@testtlnls) 2024年6月6日
GoogleのサイトがWR2（C = US, O = Google Trust Services, CN = WR2）など発行の証明書をつかっていることがあるようなので，ChromeやEdgeなどChromium系のブラウザでは紛らわしいですね． pic.twitter.com/IX6RL8lCjL
ちなみにLet's Encryptは2024年に入って1日平均の証明書発行数が400通を超えている模様。すごい。
#DYK Our average daily certificate issuance has steadily increased since our inception. In fact, we're regularly issuing more than 4 MILLION certs every day! 🤯 #TLScerts #automated #globalencryption pic.twitter.com/OaA53mTX5q
— Let's Encrypt (@letsencrypt) 2024年6月7日
▼ひとくちPKI 67
こちらのツイートから。
ちょっとだけPKIの話題を話して雑談するポッドキャスト #ひとくちPKI 最新エピソード公開しました📻よかったらきいてください :)
— Yurika (@EurekaBerry) 2024年6月5日
67: "Digicert EV証明書で大文字小文字不備のインシデントがあった話" https://t.co/lK2QOo1kVz
リンク先はこちら。
ひとくちPKI Journal 3のeIDAS 2.0の補足パートが良かったです。
メインはDigiCertのEV証明書失効の件。pkilint（リンティングツール）というか、根気強くエンジニアとコミュニケーションしてるコンプライアンス担当すごいなー。エンジニアが誤検知と言いたくなった気持ちも分かる...。Baseline Requirements違反というより、CPS(Certificate Practice Statement)違反...難しい。細かい経緯を把握できてなかったので助かりました。
▼わずかな平文通信の問題
こちらのツイートから。
Several years ago I complained that https://t.co/GEBztHXCZB doesn't use HTTPS. It still doesn't, but at least the complaint now exists in blog post form: https://t.co/dbruELRXaa https://t.co/Ukn84fkon7
— Emily Stark (@estark37) 2024年6月7日
リンク先はこちら。
HTTPでアクセスした場合にネットワークインジェクション攻撃を受けて、別のサイトを閲覧させられてしまう問題は2023年にも知られています。
そうした問題があるので、http://shrug.io/のような「¯\_(ツ)_/¯」のAAをコピーするためだけのサイトであっても、HTTPでアクセスするのは危険だ、という話がまとめられていました。
[おわりに]
技術書典16オンラインマーケットは終わりましたが、電子版なので引き続きご購入いただけます。何卒ごひいきに🙏
