2023年1月16日～2023年1月22日に読んだ中で気になったニュースとメモ書き（TLSらじお第89回の前半用原稿）です。
- [RSAの終わりの始まり]
- [Compact ECDHE/ECDSA Encodings for TLS 1.3]
- [TrustCor続報]
- [ZeroSSLのインシデント]
- [その他のニュース]
- [まとめ]
[RSAの終わりの始まり]
こちらのツイートから。
ちょっと危機感を持ったので書いてみました。
— LE宮地 (@le_miyachi) 2023年1月18日
RSAの終わりの始まり - 暗号移行再び https://t.co/Y0AWAgOjVd #Qiita
リンク先の記事はこちら。
今一般的に使われているTLSサーバ証明書がRSA2048ビットなのは、先週もMerkle Townのニュースで触れた通り。これを2030年までに移行するには...というお話。
自分がこの業界に入ったのがちょうど11年前で、まさに80ビット安全性から112ビット安全性への移行(RSA 1024ビット/SHA-1からRSA 2048ビット/SHA-2)の真っ只中だったようだが、全く記憶にない...。
ぼんやりとそろそろRSA 2048の証明書を使えるのもそろそろ終わりかな...と考え始めていたタイミングだったので、身の引き締まる思い。
もしまだ自分のかかわるサービスで移行計画が無いようでしたらまず検討を始めましょう。
はい、検討始めます...。いつまでもRSA使ってるとECDSAに乗り換えるタイミング逃しそうだからちゃんとやらねば。
[Compact ECDHE/ECDSA Encodings for TLS 1.3]
こちらのツイートから。
Compact ECDHE and ECDSA Encodings for TLS 1.3https://t.co/BUy0leutUf
— ゆき (@flano_yuki) 2023年1月17日
ECDHEやECDSAのエンコーディングを改善して転送量削減する提案#yuki_id
リンク先はこちら。
新しいインターネットドラフトが出た模様。提案者はスウェーデンの通信機器メーカーEricssonの所属。そういえば昔Ericssonの携帯電話あったなあ...。
TLSの鍵交換で利用されるECDHE(Ephemeral Elliptic-curve Diffie–Hellman, 一時的楕円曲線ディフィー・ヘルマン鍵共有)や、ECDSA(Elliptic Curve Digital Signature Algorithm, 楕円曲線DSA)では通常可変長の署名を生成する。これらのオーバヘッドが大きいため、コンパクトな固定長のエンコーディングを利用して、TLSの速度改善を測ろうという試みらしい。
楕円曲線の計算の詳しい部分は全然理解できていないが、点を表す座標xとyをこれまで送っていたものをxと他の共有済みのパラメータからyを計算できるのでyを送信するのをやめて、バイト数を半分くらい減らすことができるとのこと。よくわからんけどすごそう。
cTLS(Compact TLS)で特に有効だとか。cTLS一回ちゃんと読まないとな...。
[TrustCor続報]
こちらのツイートから。
Googleもようやく。Chromiumからはもうちょっと前から消えてた気もするがhttps://t.co/u9BFdJPSUx
— matsu卯 (@matsuu) 2023年1月17日
リンク先の記事はこちら。
既に何度か書いたTrustCor認証局の件。
2023年3月に正式リリースされるバージョン111から、ChromeはTrustCorを削除するとのこと。EdgeやFirefoxに続き、ようやく。
Macはいつになるんだろう...。
AppleはまだTrustCor消してないな。
— matsu卯 (@matsuu) 2023年1月17日
/システム/ライブラリ/Security/Certificates.bundle/Contents/Resources/TrustStore.html で確認が可能。
自分はまだmacOS MontereyでKeychainにTrustCorが入っているんだけど、Venturaに上げたら削除されてたりするんだろうか。ブラウザの対応の方が早そうだからChromeの対応待ちかな...。
[ZeroSSLのインシデント]
こちらのツイートから。
ZeroSSL: XSS leading to session hijacking, stealing a private key (and a password hash) https://t.co/GjbuuxoA6a
— Frank ⚡ (@jedisct1) 2023年1月19日
リンク先はこちら。
Sectigoルート認証局の中間認証局(リセラー)であるZeroSSLのサイトにXSS脆弱性があり、証明書の秘密鍵をダウンロードできる状態にあったとのこと。
類似の案件としては、2008年のStartCom社のサイトの脆弱性が悪用された件が思い出されるが、あのときは誤発行された証明書は数分で失効されたのと比べると今回の方が影響は大きいと思う。
自分はぼんやりとZeroSSLのような中間認証局を正規の認証局だと思っていたのだが、証明書の「発行者 issuer」表示を鵜呑みにしてはいけない、と書かれていた。
You might think ZeroSSL is a certificate authority because the name "ZeroSSL" appears in certificate issuer fields.
— Andrew Ayer (@__agwa) 2023年1月19日
But as I explained yesterday, the issuer field is a lie: https://t.co/rLk3zXz2Tb
当然、認証局ではないので、証明書発行可能な認証局を制御するDNSのCAAレコードを利用する際はZeroSSLではなくSectigoの方を指定することになる、という話。なるほど...。
[その他のニュース]
▼ACMEクライアントのフェイルオーバ
こちらのツイートから。
Every ACME client should fail over across CAs like Caddy. https://t.co/XdqJkYo2W3
— Ryan Hurst (@rmhrisk) 2023年1月19日
ACMEクライアントのフェイルオーバで、いろんな認証局を使えるようにしているよ、という話。
確かに、証明書自動更新の際に認証局が落ちてて証明書を作れなかったら大問題ではある。特に、有効期限を短くして運用している場合は。
ただ、どこの認証局でもいいというわけではないケースもあると思うので、難しいところ。
▼2つのSCT
こちらのツイートから。
Two SCTs per certificate is already painful to make post-quantum secure. Looks like the number of SCTs might go up! https://t.co/E5kEXyUrHx
— Bas Westerbaan (@bwesterb) 2023年1月19日
リンク先はこちら。
ChromeのCT(Certificate Transparency)要件の1つに、証明書のCTログがリタイアしていないこと、というのがあるが、リタイア以前のものは信頼しても良いのではないか？という疑問からスタートしている。
SCT(Signed Certificate Timestamp)はCTログに証明書を登録した際に返却され、これを証明書とともにクライアントに2つ返却し、CTのチェックが行われるが、2つともCTログがリタイアしている場合はどうなるのか、3つ以上必要なのでは、というのがツイートの話。
通信量がまた増えることになりそう...cTLSとかがさらに重要になってくるのかな。
[まとめ]
調べれば調べるほどわからないことが増えてきてつらい...。
