2023年4月3日～2023年4月9日に読んだ中で気になったニュースとメモ書き（TLSらじお第100回の前半用原稿）です。
[Levchin Prize 2023]
YouTubeを徘徊していて見つけたこちらの動画から。
サイトはこちら。
過去にはLet's EncryptやOpenSSLチームなどの団体のほか、暗号界隈で活躍した個人に贈られているLevchin賞の2023年の受賞者が決まった。
今年は、AESの元になったRijndael暗号の提案者であるVincent Rijmen氏*1と、Spectre脆弱性の発見やSSL3.0のドラフト作成で知られるPaul Kocher氏がそれぞれ受賞した模様。
お二方とも、長年にわたりさまざまな業績を残していてすごい...。
[CloudflareのmTLSバグ]
こちらのツイートから。
This blog post outlines the root cause analysis and solution for a bug found in Cloudflare’s mTLS implementation. https://t.co/GzsnoeMV7l
— Cloudflare (@Cloudflare) 2023年4月3日
リンク先はこちら。
失効したクライアント証明書とセッション・リザンプションの相性が悪かった、という話らしい。悪かったというかバグってたというか。
リソース消費の激しい認証と鍵交換のプロセスをスキップするのがセッション・リザンプションの目的なので、言われてみればあるある...みたいな感じだけど、事前にテスト観点として洗い出せるかと言われると難しいかも。
にしても、こうやってバグの詳細をきちんと公開できるのすごい。
[OCSPレスポンスのSCT]
前々回のニュースにお便りが届きました。ありがたや...!
SectigoのCTログ障害の件に関連して、OCSPステープリングのレスポンスにSCTを埋め込める話が初耳だったって話を書いた。
これに対して、ZeroSSLという認証局が昔対応していたとのお話が。なるほど。
よくわからん上にメリットもなさそうだし、なんなんだろうこの仕様...。
お便りをくれたtesttlnlsさんは他にも関連する内容をツイートされていた。フォローしておかねば。
ZeroSSLのACMEではOCSP Must-Stapleは未対応のようですが、発行数制限があるWeb（またはREST API）注文ではOCSP Must-Stapleに対応しているようなので試してみましたが、
— testtlnls (@testtlnls) 2020年9月8日
Sectigoの証明書はOCSP Must-Stapleを入れた場合のみOCSP応答にSCTが入るらしく、OCSPデータ量が肥大化https://t.co/XmXwpEUaXg pic.twitter.com/AxlHiVwaaF
OCSP応答に入るSCTも証明書埋め込みSCTと同じログのSCTなので完全にかぶることになります。 2年くらい前は（当時はCOMODO CA）すべてのOCSP応答にSCTが入っていましたが、いつからかOCSP Must-Stapleの入った証明書のみになったようで。
— testtlnls (@testtlnls) 2020年9月8日
Let's EncryptはOCSP Must-Stapleを入れてもOCSPにSCT入りません
ACMEに対応してないんだとしたら、ますますOCSP+SCTって何に使うのかわからんな...。2022年には非対応になった模様。
３月のどこかからZeroSSL（Sectigo全般？）でOCSP Must-Stapleの証明書をリクエストすると，
— testtlnls (@testtlnls) 2022年5月16日
SCT埋め込みのない証明書を発行するようになったようです．
添付画像では，OCSP Must-Stapleのない43，46，49はファイルサイズが同じなのに対し，他は3/26より3/4のファイルサイズが大きいことがわかります． pic.twitter.com/F7pnbLnRv2
[その他のニュース]
▼e-Tugra認証局のその後
こちらのツイートから。
This e-turga incident report is one of the worst WebPKI reports I've seen. Sunlight is truly the best disinfectant. https://t.co/GXgZo5d5Sz
— Ryan Hurst (@rmhrisk) 2023年4月2日
ライアンさん、スペル間違えてますよ...。
去年の11月にセキュリティ上の問題が発覚したトルコのe-Tugra認証局について取り上げた。その続報、というか現状。
e-TugraのAhmed氏はペネトレーションテストを実施して問題を修正したと主張しているが、Ryan Hurst氏は今回のテストに半年もかかっている点を指摘している。確かにあまり誠実な対応をしているようには見えない。
トルコ語の読める開発者も、ペネトレーションテストの報告書からは何も読み取れないと言っている。残念...。
▼BoringSSLのKyber対応
こちらのツイートから。
[BoringSSL] Adding a C implementation of Kyber.https://t.co/jxQDAI7UiX
— ゆき (@flano_yuki) 2023年4月2日
リンク先はこちら。
BoringSSLはOpenSSLをGoogleがフォークしたバージョン。
最適化もまだだしAPIも安定版ではない、もののC言語での耐量子暗号Kyberが実装された。
ちなみに、2021年の日銀の資料だと「ケイバー」という読み仮名が振られていた。スターウォーズファンとしては「カイバー」だと思っていたんだけど、どっちが正しいんだろう...YouTubeでいくつか動画見た感じだとカイバー派が多そうな印象。
▼IPAサイト改変後のリンク集
こちらのツイートから。
PKI、署名、暗号関連でリンク切れになったIPAページのリンク集を自分用に作っておきました。よかったら使ってやってください。https://t.co/SAxcqAdU62
— kjur (@kjur) 2023年4月4日
リンク先はこちら。
URLはほぼ一緒なのだから、これくらいならリダイレクトしてほしいよなあ...。
▼サブドメインACMEのドラフト
こちらのツイートから。
【自分用メモ】現在RFC Ed Queue。
— Yasuhiro Morishita (@OrangeMorishita) 2023年4月5日
draft-ietf-acme-subdomains-07 - Automated Certificate Management Environment (ACME) for Subdomains https://t.co/OxOif6b2s7
リンク先はこちら。
サブドメインの所有権を証明しなくても、親ドメインの所有権を証明しておけばサブドメインへACMEを利用できるようにする、というドラフトが提案されているらしい。
どうせ自動なんだからサブドメインも個別に所有権確認したらいいのに、と思うけどきっと何か問題があったんだろうな...サブドメインの個数が自分の想像してるやつと桁が2つ3つ違うとか。
▼HTTPSオンリーモードの強制
こちらのツイートから。
Chrome's "Always Use Secure Connections" setting, which attempts all navigations over HTTPS first, and shows a bypassable warning if HTTPS is unavailable, can now be force-enabled via enterprise policy as of Chrome 112. https://t.co/HoeMY76DCz
— David Adrian (@davidcadrian) 2023年4月6日
リンク先はこちら。
2023年4月4日にリリースされたChrome 112から、エンタープライズポリシーを利用して、HTTPSオンリーモード（HTTPだと警告画面がでる）を強制することができるようになるらしい。
社内サイトなどHTTPSに対応していない場合は許可リストに追加すれば良さそう。
You can also specify an HTTP allowlist, e.g. for corporate internal sites or shortlinks that are not available over HTTPS.https://t.co/En89jNlCfQ
— David Adrian (@davidcadrian) 2023年4月6日
[まとめ]
そういえばTLSの勉強をはじめて2年くらい経つみたい。まだ何もわからんな...というのがわかっただけでも進歩しただろうか。
*1:Rijndaelを一緒に作ったJoan Daemen氏は既に2017年にLevchin賞を受賞している。
