2025年1月13日～2025年1月19日に読んだ中で気になったニュースとメモ書きです。
[6 day & IP Address Certificate]
こちらのツイートから。
Let’s Encrypt: Announcing Six Day and IP Address Certificate Options in 2025 https://t.co/VxcOdFWIz8
— Frank ⚡ (@jedisct1) 2025年1月16日
Let's Encrypt から有効期間6日の証明書(短期間証明書)に関する正式な発表がでました：
— Yurika (@EurekaBerry) 2025年1月16日
・２月からLEに向けて開始し4月から早期導入ユーザーに展開。2025年中には全ユーザーに展開したい
・現行の90日間証明書も引き続きサポートhttps://t.co/WU5TuvQHK9 https://t.co/lcDuH7Fcr3
・短期証明書はACME API に追加される新プロファイルでのオプトイン
— Yurika (@EurekaBerry) 2025年1月16日
・サブジェクト代替名として IP アドレスを含めることをサポート
・IP アドレスの検証はhttp-01 および tls-alpn-01 チャレンジ タイプのみ
なんで短期証明書を推奨してるの？
— Yurika (@EurekaBerry) 2025年1月16日
→失効確認の機能は現状うまく機能しておらず、結果的に有効期限まで使われることが多い。証明書の有効期間が短いほど潜在的な侵害の可能性が大幅に減少する
→有効期間が短い証明書には実質的に自動化が必要で、自動化はセキュリティ上重要である
・短期証明書には、OCSP または CRL URL は含まれません
— Yurika (@EurekaBerry) 2025年1月16日
そうなんだ👀
リンク先はこちら。
Let's Encryptが6日間の短期証明書を発行する件は、昨年末に発表されていた。
追加で、6日間の証明書についてはIPアドレスをSAN（Subject Alternative Name）に含めるパターンもサポートするらしい。どういうニーズだろう...気になる。IPアドレスの場合、DNSが使われないのでCAAのような仕組みが使えないとのこと。それはそうか...。
2月になったらLet's Encryptのサイトの証明書がどうなってるのか見に行かなきゃ！
[その他のニュース]
▼Entrustのルート変更
こちらツイートから。
【自分用メモ】https://t.co/98KNmbiVbO のサーバー証明書が、SSL\.comがルート認証局、EntrustがSubCAになっているものに変わった。 pic.twitter.com/EX010ySLa9
— Yasuhiro Morishita (@OrangeMorishita) 2025年1月15日
一連のインシデントを受けてChromeやFirefoxから信頼されなくなったEntrustがルート認証局を変更する方針は伝えられていたが、いよいよ実施されたっぽい。
果たして復権なるか。
▼HTTPS-First / HTTPS Upgrades (Firedox 136)
こちらのツイートから。
Gecko: Intent to ship: HTTPS-First / HTTPS Upgradeshttps://t.co/NAmFicZL3j
— Intent To Ship (@intenttoship) 2025年1月15日
リンク先はこちら。
半年ほど前にNightlyでリリースされていた機能がいよいよ正式リリース予定（2025年3月）とのこと。
▼Hybrid key exchange in TLS1.3 ドラフト12版
こちらの記事から。
これまで、鍵交換に利用する耐量子暗号アルゴリズムはKyberと表記されていたが、2024年夏のNISTがKyberをML-KEMとして標準化したので、そちらの名称に修正した模様。
ML-KEMを取り上げたインターネットドラフトが出てきているので、そちらも参照されている。
▼curlのSecure Supportサポート廃止
こちらの記事から。
Appleの（macOSやiOSの）TLSライブラリSecure TransportはApple自身もレガシー扱いで非推奨なのでサポートやめるよ、とのこと。TLS1.3をサポートしてないようなので、仕方ない。
それでもまだ10のTLSライブラリをcurlがサポートしているらしい。すごい。
▼マイナンバーカードのアルゴリズム
こちらのツイートから。
RSA2048と量子コンピュータの話がこんなところで出るとは。 https://t.co/SvKxGTNTO3
— Hiroki KUNII (@hkuni) 2025年1月17日
マイナンバーカード、RSA2048ビットなんだ...。去年新規取得したけど、5年で切れるから2029年中には新しい方式のカードになるのかな。楕円曲線になるのか、RSAのままビット数増やすのか、気になるところ。
こんなツイートも。ECDSAはダメだから、Ed25519かなあ...これは厳密には楕円曲線じゃないんだっけか...。
マイナンバーカードの次期仕様はECDSAの予定とあったけどEd25519かRSA4096bitにすべきと思うhttps://t.co/mnIruI1e53
— ますだまさる (@m_masaru) 2025年1月17日
理由はECDSAに使う乱数が1bitでも偏ってると破られるのがここ数年で分かったから
LadderLeak: Breaking ECDSA With Less Than One Bit Of Nonce Leakage https://t.co/cqZSei29bD https://t.co/5YIJRfMviH
去年のこれとかが実例https://t.co/q6gsaT2qEU
— ますだまさる (@m_masaru) 2025年1月17日
PuTTY SSH クライアント実装には、ECDSA 署名処理の実装に脆弱性があります。
NIST P521 楕円曲線による ECDSA 秘密鍵を使っている場合、署名を行う際に生成する nonce に偏りがあります (CVE-2024-31497、CWE-1240)。…
2008年にNISTが予想した想定と異なり2030年はRSA 2048bitの方がECDSAより堅そうというのが実情
— ますだまさる (@m_masaru) 2025年1月17日
RSA高ビットが予想より堅かったのと、ECDSAの乱数への期待がピーキーすぎたのが原因
ただDual_EC_DRBGの件を考えるとNISTはECDSAが偏った乱数に弱いのを知ってた可能性もそれなりに高いhttps://t.co/6a9Twhupfl
— ますだまさる (@m_masaru) 2025年1月17日
▼mitmproxy2swagger
こちらのツイートから。
REST APIへの通信をmitmproxyを使ってキャプチャーしてリバースエンジニアリングでOpenAPI 3.0なspecファイルを生成するツール。あーいいねぇ。 / “GitHub - alufers/mitmproxy2swagger: Automagically reverse-engineer REST APIs via capturing traffic” https://t.co/xOjceDYX14
— matsuu (@matsuu) 2025年1月12日
リンク先はこちら。
MITMというと攻撃っていうイメージが強かったけどこういう使い方もできるか。便利そう。
[おわりに]
ぼちぼち次の技術書典の準備を始めてます。
