2022年10月10日～10月16日に読んだ中で気になったニュースとメモ書き（TLSらじお第76回の前半用原稿）です。
[DHEat Attack]
こちらのツイートから。
If you're wondering about how much exactly is DHE slower, here's an illustration from Bulletproof TLS and PKI. https://t.co/dlHpSBb3rS pic.twitter.com/9t0gHZX2ke
— Ivan Ristic (@ivanristic) 2022年10月13日
Cloudflare customers are unaffected by https://t.co/Aen1lFgn2R, aka CVE-2002-20001 (no typo, it's really that old), because Cloudflare doesn't support Finite Field Diffie-Hellman in TLS. Since it's a CPU DoS, it wouldn't have affected customers anyway, just Cloudflare servers.
— Nick Sullivan (@grittygrease) 2022年10月13日
DHEAT ATTACK - DoS attack that can be performed by enforcing the Diffie-Hellman key exchange https://t.co/V4DeeOOtrN - Kill legacy algorithms. Kill them, like BoringSSL does.
— Frank ⚡ (@jedisct1) 2022年10月13日
脆弱性のサイトはこちら。
DHE鍵交換を強制することで、被害者のCPUを加熱することから、DHE+heatでDHEat攻撃というらしい。TLS以外にもSSHやIPSecも攻撃対象とのこと。
CVE-2002-20001とある通り、元の論文は20年前のものだが、2021年11月に有効性が実証され、今回サイトが作成された感じっぽい。サイトの説明では、TLS1.2+RFC7919またはTLS1.3で、ClientHelloを送ってDHEを選択させるだけなので、100バイト程度送信するだけで十分とのこと。TLS1.2以下ではDHEの鍵サイズをネゴシエートできず、あまり効果的でないらしい。
攻撃用のツールとしてD(HE)aterが公開されている。
[CRL Issuing Distribution Point]
こちらのツイートから。
CRLのIssuing Distribution Pointに関する問題提起。CCADBで導入されたJSON形式の分割CRL、CRLSet、CRLLiteは情報端折って置いてる、
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年10月11日
ある部分のセキュリティ設計を無視した標準化されない失効検証に興味ない人の独自方式なのでどんな事故が起きても仕方ないよね。https://t.co/DZXLoEHTLz
しかし、OCSP Stapling使えばOCSPでもプライバシー問題は気にしなくていいようにしたのに、今更OCSPのプライバシー問題を持ち出してヘンテコCRL回帰が起きるとは思わなかったですよ
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年10月11日
WebPKIは、名前制約とかポリシ制約とか多様な失効検証モデルとかを削ぎ落とした、もうちょっと(限定された)失効検証を大切にするシンプルなWebPKIプロファイルを標準化したほうがいいと思うの、、、失効検証一切しない実装がまかり通ってて事故起きるよね
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年10月11日
リンク先はこちら。
ここ半年でチラホラ目にするようになったCCADB（Common CA Database）。5月のニュースでMozillaのルートストアポリシー変更があった時にも登場していた。
CRLに関するRFC 5280で定義されているIDP拡張機能は、CRLのDistribution Pointとどういった種類の失効理由をカバーしたCRLかといった情報が含まれる。ちゃんと認識していなかったけど、CRLもX.509証明書のように拡張があって、criticalとかnon-criticalといった区別があるようだ。
IDP拡張機能に含まれるDistribution Pointと検証対象の証明書に含まれるDistribution Pointを比較してから、CRLの中身を検証する、といった使い方をするらしい。
で、CCADBで定義されているやり方では、IDP拡張機能がないので、HTTPでやり取りされるCRLを攻撃することで、証明書の失効を「隠す」ことが可能になるらしい。
どんどんぐちゃぐちゃになっていくなあ...。
[ChromeとEV証明書]
こちらのツイートから。
No More EV Certificate Overhead in Chrome 106https://t.co/fZzgzjiGFc
— kjur セキュリティ IT 開発の私的情報収集用＋少しつぶやき (@kjur) 2022年10月13日
リンク先はこちら。
Google Chromeバージョン106から、EV証明書のOCSPによる失効チェックをデフォルトで行わなくなるとのこと。速度改善は良い。
記事ではwww.digicert.comへの接続にChrome 105では、OCSPのためオーバヘッドが573msかかっているとのこと。500ms超えてると流石に人間が気付くレベルな気がする。でも今どれだけのサイトがEV使ってるんだろう...?
[その他のニュース]
▼HTTP/2を誤解していた話
2017年の記事から。
最近標準化されたHTTP/3が暗号化必須のQUICをベースにしていたこともあり、HTTP/2もなんとなく暗号化必須なのだと誤解していた。
しかし、上の記事にもあるようにHTTP/2はHTTP/1.1と互換性があり、暗号化していないHTTP通信も可能で、接続方式を区別する識別子として「h2」（HTTP/2 over TLS）と「h2c」（HTTP/2 over TCP、HTTP/2 Cleartextの略）がある。
Google ChromeやFirefox、Safari、Internet Explorerといった一般的なWebブラウザはh2cに未対応となっているため、HTTP/2を利用するためには事実上TLSが必須という状況になっている
ブラウザの実装としてはh2cがないので、開発者ツールで見ていてもh2cに気づかなかった。なるほど。
▼HTTPSレコードドラフト11版
こちらのツイートから。
New revision 11 of Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs) published. https://t.co/sHVBQhhKs2
— DNS Operations Working Group (@ietf_wg_dnsop) 2022年10月11日
リンク先はこちら。
8月のニュースで取り上げたHTTPSレコードのインターネットドラフトが11版になったようだ。
変更点としては、11.3. Operational considerationsが追加されたくらい？
▼OpenSSL Security Advisory [11 October 2022]
こちらのツイートから。
OpenSSL Security Advisory https://t.co/Ce8xQNOic3
— OpenSSL announce (@OpenSSLannounce) 2022年10月11日
リンク先はこちら。
CVE-2022-3358。OpenSSLでカスタム暗号を使うと、暗号化されず平文がそのまま出力されるケースがあったらしい。NULL encryptionって言うんだなー。
▼Telegram Messenger
こちらのツイートから。
Wait, what is Telegram doing here? https://t.co/HQAIrs3YPB
— Matthew Green (@matthew_d_green) 2022年10月13日
TLSのSNI拡張でなぜかユーザー名が送信されているらしい。以下の公式アカウントの説明によると、多分ユーザープロファイルか何かを開く際のリンクがサブドメイン方式とパス方式があって、前者を利用するケースでは仕方ないらしい。プライバシーの観点からは設計がよろしくない気がする...。
If a link in the optional format “https://t.co/PtycZDviVY” is opened from a third-party resource, we can’t prevent your Internet service/DNS provider from getting this information. But you can use the default format “https://t.co/UMeITLnG9t” to avoid this.
— Telegram Messenger (@telegram) 2022年10月13日
[まとめ]
AIで暗号解読...そういう使い方もあるんだな。機械学習にちょっと興味出てきたかも。
暗号解読できちゃうのかな！？→「ニューヨーク・タイムズによると、アメリカの諜報機関は「中国はスーパーコンピューターとAIを駆使して、ステルス兵器や極超音速兵器を開発し、さらにアメリカ政府の暗号化されたメッセージを解読しようとしている」と報告しているとのこと」 https://t.co/KSSN2FCV83
— Takamichi Saito, 齋藤孝道 (@saitolab_org) 2022年10月14日
