2023年5月15日～2023年5月21日に読んだ中で気になったニュースとメモ書き（TLSらじお*1第106回の原稿）です。
[CTログのビット反転]
こちらのツイートから。
CTログでビット反転再び。機器エラーか宇宙線か不明だがちょくちょく発生してしまう。 https://t.co/PDMVTNGvuR
— matsuu (@matsuu) 2023年5月14日
宇宙線とかでビット反転が起きるって話は昔何かで聞いたことあるけど、実際に問題を起こしてる例は初めて聞いたな...。
リンク先はこちら。
Nessie 2024はDigiCertのCT(Certificate Transparency)ログ。登録されたログのSubjectPublicKeyInfoの51番目のバイトが本来0x92であるべきところ、CTログ上は0x93となってしまっているらしい。
Merkle Treeは（後述のひとくちPKI第16回によると）数珠繋ぎの署名になっている。結果として全体が検証できなくなるためか、DigiCertは当該CTログの稼働を停止したとのこと。確かに、CloudflareのMerkle Townで確認すると、TREE GROWTHのグラフがしばらく0になっている。メーリス上では、停止に際してGoogleの指示があったという情報もあるが詳細は不明。
「少なくとも1つのリタイアしていないCTログが必要」というChromeの要件上CTログを複数持っておく必要があるが、ビット反転対策とかも考えるといくつ持っておく必要があるんだろうか...。
ちなみに
CTログベースだと、最近の認証局ごとの証明書数は以下のようなグラフになるらしい。
For what it’s worth this is what the issuance by CA looks like as of today based on CT logs. https://t.co/bUKU68h3w3 pic.twitter.com/vvWi5TNj8E
— Ryan Hurst (@rmhrisk) 2023年5月16日
今回の障害に関連して、2021年にもDigiCertのYeti 2022というCTログで同様の事例があった。
CTログのビット反転についてはひとくちPKIの第16回が詳しい。29:00頃から https://t.co/Ms4YTWkNBQ
— matsuu (@matsuu) 2023年5月14日
過去に発生したCTログのビット反転の詳細はこちら https://t.co/mGwfjpSmRf
— matsuu (@matsuu) 2023年5月14日
Agwa氏のブログによると、こうした障害によって証明書の大量の置き換えが発生するケースがあり、これに対処するためにLet's EncryptがARI(ACME Renewal Information)の開発に取り組んでいたらしい。そういう背景もあったのか〜と納得。
他にも似たような原因でCTログが廃止になった事例があるらしい。壊れやすいんだな...。
5/30にDigiCert Nessie2024 CTログがRetiredになるようです． DigiCert CTのログが回復不可能なデータ破損により廃止になるのはYeti2022，2022-2，2023に次ぐ４例目です． pic.twitter.com/CnkvzIOHTT
— testtlnls (@testtlnls) 2023年5月17日
[NIST SP 1800-16]
こちらのツイートから。
大中規模な企業が証明書のリスクを特定して対処できるようにする証明書管理プログラムとのこと。
— 菅野 哲 / GMOイエラエ 取締役CTO (@satorukanno) 2023年5月16日
サーバ証明書の管理に関するガイダンスのリンクがあったりと情報が整理されていて素敵なサイトですっ！
TLS Server Certificate Management,https://t.co/91onAGaO1Y#TLS #NIST #X509
リンク先はこちら。いくつかリンクがあり、Web版もある。
Aが経営者向けのまとめで、Bがベストプラクティス集っぽい。
証明書の一元管理だけじゃなくて、組織として利用する認証局も管理しましょうねって書かれてた。なるほど。証明書のインストールや更新も自動化しましょうねって書かれてた。はい...。
一気に全部読むには長すぎるので、毎日ちょっとずつ読んでいくかChatGPTに食わせるかして消化したい。
[CAAレコードの実態]
こちらのツイートから。
I looked up CAA records for ~214M domain names in almost 1,200 TLDs as well as across the Tranco Top 1M Domains list.
— Jan Schaumann (@jschauma@mstdn.social) (@jschauma) 2023年5月14日
In total, <3 M domains have CAA records; <50K of the Top 1M domains. That's barely 1.4% of all TLDs (4.8% of Top 1M domains) -- not that great, adoption wise. pic.twitter.com/bEOyx6rsZq
CAAレコードというのはDNSレコードの一種で、そのドメインに対してどの認証局が証明書を発行できるか、を指定できる。2017年からCA/B Forumで認証局に対して遵守が求められているルールだ。
ツイートによると約2億のドメイン中、CAAレコードがあるのは300万ドメイン未満。1%ちょっとしかない。Tranco Top 1Mドメインに絞ると、4.8%程度にはなるらしいが、それでもまだまだ全然普及しているとは言い難い状況。
この手のアクセス数の多いサイト調査のときにはこれまでAlexaが利用されていたが、Trancoというサイトが今後使われていきそう。
アクセス数の多いサイトランキングをAlexaが公開してたんですが2022年5月1日にサービス終了しました。Trancoというサイトが調査用に情報提供してくれているそうです。ありがたやありがたや。https://t.co/OHKmSytqTL
— kjur (@kjur) 2023年5月17日
CAAレコードで利用されている認証局としては、Comodo、DigiCert、Let's Encryptで全体の75%を占める様子。
And finally, and most importantly:
— Jan Schaumann (@jschauma@mstdn.social) (@jschauma) 2023年5月14日
4) A small number of CAs dominate.
Only 7 Certificate Authorities account for over 99% of all CAA 'issue'/'issuewild' records (10 CAs for 99% of the Top 1M Domains).
3 alone account for over 75%: Comodo, DigiCert, and Let's Encrypt.
2、3の認証局を指定してCAAレコードを指定するイメージだったので、あまり数は多くないと思っていた。しかし、以下のツイートによると、1ドメインにつき4〜5レコードが多数派だが、50レコード以上も指定しているドメインもあるとか。
For the domains that _do_ have CAA records set, the most common number of records is small, e.g., four or five CAs authorized to 'issue' and 'issuewild':
— Jan Schaumann (@jschauma@mstdn.social) (@jschauma) 2023年5月14日
But over 900 domains have more than 20 CAA records, and a few even more than 50! pic.twitter.com/P2uHss0O8A
CA/B Forumで追加された証明書発行時の連絡先として指定できるcontactemailタグがあるが、RFCに反映されていないこともあってか、利用はまだごく少数とのこと。
RFC8659 defines three different properties: 'issue', 'issuewild', and 'iodef'. That's it.
— Jan Schaumann (@jschauma@mstdn.social) (@jschauma) 2023年5月14日
(CA/B Forum Ballots SC13 & SC14 added 'contactemail' and 'contactphone', but those aren't part of the RFC; I only encountered 741 and 23 uses of these respectively, so let's ignore them.)
RFC 8657で追加されたaccounturi拡張についても同様。
RFC8657 specifies the 'accounturi' & 'validationmethods' parameter extensions.
— Jan Schaumann (@jschauma@mstdn.social) (@jschauma) 2023年5月14日
There's also a draft extension for Signed HTTP Exchanges ('cansignhttpexchanges') that appears to only be supported by DigiCert and pki dot goog.
The usage of these parameters is quite limited: pic.twitter.com/OAL3puFTVC
スレッドの内容はブログにもまとめられている。
@kjurさんが日本語でもまとめてくれている。
Signs of Triviality
— kjur (@kjur) 2023年5月17日
Whose Cert Is It Anyway?https://t.co/giCxwGshev
CABF BRではSSLサーバー証明書を発行する際にDNSのCAAレコードを確認するルールになっていると思いますが、CAAレコードを設定しているドメインはとても少なく、また、設定自体も不適切なものが多すぎるという調査報告です。
ちょっと見たところ、Facebook、Google、Cloudflare、DigiCert、GlobalSignのドメインはCAAレコードを設定していますが、Twitter、インスタグラム、IBM、Microsoft、SectigoなどのドメインはCAAレコードを設定していないようです。
— kjur (@kjur) 2023年5月17日
なんか、動的HPKP、動的HSTSと似た話になっちゃってますねぇ
— kjur (@kjur) 2023年5月17日
主に2017年以前の情報を元に書かれたプロフェッショナルSSL/TLSを読んだときに、どの認証局でもあなたのドメインに対して証明書を発行できてしまう問題がある、と書かれていた。その問題を知っていたので、解決策になりうるCAAレコードについて知ったときはすごい仕組みだな、と思ったんだが...現実は非情である。
[CAは信頼できるか？]
こちらのツイートから。
📝Splunk SURGe teamが50億のTLS証明書から、CAがどのようにウェブサイトのアイデンティティを検証しているかを分析。14 のCAはリスクありとの結果。
— Yurika (@EurekaBerry) 2023年5月18日
Trust Unearned? Evaluating CA Trustworthiness Across 5 Billion Certificateshttps://t.co/fvKn8BrvTt
リンク先はこちら。
@kjurさんは結果にやや懐疑的なご様子。確かに、ここに上がってる認証局だけが危ないのか？というと他にも危ないところはありそう（逆のケースももちろんありうる）。
所々、リスクスコアがなんでそうなったのか？と疑問に思う箇所もあり、リスクスコアの計算方法も開示されないのにスコア高いよ！と言われても、何だかなぁ、、、という気もします。
— kjur (@kjur) 2023年5月18日
14のCAが危ないとか言ってますが、それも匙加減で決めてるんですよね〜〜〜
— kjur (@kjur) 2023年5月18日
ただ、上記記事でリスクのあるルート認証局として指摘されているトルコのe-Tugra認証局は、本ブログで度々取り上げている通り、あまり安全とは言えない状態だった気がする。インシデントからの復旧後はどうなったか分からないけど...。
[その他のニュース]
▼ACMEフローチャート
こちらのツイートから。
Understanding ACME via a conversation with Jack and Jill as they went up the hill to fetch a X.509 certificate. #certificatelifecycle #acme #standards #NoMoreExpiredCerts #uptime pic.twitter.com/sTHwAwzIQN
— Ryan Hurst (@rmhrisk) 2023年5月11日
ACMEなんか難しそうだなと思ってたけど、普通の証明書発行の手順とそう違わなそうだった。なるほど。
▼Certify v6.0
こちらのツイートから。
This is fantastic! @certifytheweb has become the first general-purpose ACME client that supports STIR/SHAKEN! Now, service providers have the convenience of managing both their STIR/SHAKEN and TLS certificates through the same platform! https://t.co/VcXLZ7QyZE
— Ryan Hurst (@rmhrisk) 2023年5月12日
リンク先はこちら。
Certifyという証明書管理ツールがあるらしい。
目玉機能として取り上げられているSTIR/SHAKENは、Wikipediaによると公衆電話ネットワークでのなりすましを防ぐためのプロトコルっぽい。そういうとこでも証明書が使われてるんだな...北米限定ぽいけど。
▼OpenSSL s_clientのQUICサポート
こちらのツイートから。
[OpenSSL] Add QUIC support to s_clienthttps://t.co/d5Zm6VP2vw
— ゆき (@flano_yuki) 2023年5月12日
OpensSSLのCLIがQUICサポートした。ビルドして試したけどハンドジェイクちゃんと動いてそう
リンク先はこちら。
リリース一覧を見る限りまだ正式リリースはされていないものの、OpenSSLのs_clientコマンドでQUICをサポートするコミットが入ったとのこと。
ロードマップによるとOpenSSL3.2でクライアント実装を提供予定らしい。
▼DNSCrypt
こちらのツイートから。
Ive just updated the DNS-crypt blog post to be more relevant for macOS Venturahttps://t.co/3Yr7rd4ZcI
— SweetP Productions (@SweetP_Pro) 2023年5月12日
リンク先はこちら。
DNS-over-HTTPSなどを利用してDNSの通信を暗号化するためのプロキシがあるとのこと。検討中の仕様Encrypted Client Helloとかと組み合わせると通信先ドメインを第三者が知るのはほぼ不可能になりそう。
名前のもとになったDNSCrypt自体がDNSを暗号化するプロトコルらしい。
ECHは検討中とはいえ、Chromiumに実装されていて、QUICでもECHが使えるらしい。
[chromium] Enable EncryptedClientHelloQuic by defaulthttps://t.co/GICZwzLNjg
— ゆき (@flano_yuki) 2023年5月21日
TLS ECHが有効になってればQUICでもECH使うよって感じか
▼ARIのハッシュアルゴリズム
こちらのツイートから。
ARIのハッシュアルゴリズムは，
— testtlnls (@testtlnls) 2023年5月14日
Let's EncryptはSHA-256のみ可，
GTSCAは，だいたいなんでもよさそうです．
確認済み：MD5，SHA-1，SHA-2，SHA-3
ACME Renewal Information拡張に関する情報。ドラフトでは以下のようにASN.1の証明書IDをBase64エンコードして、ハッシュ化したものをURLに含めてARIをリクエストするらしい。
GET https://example.com/acme/renewal-info/ MFswCwYJYIZIAWUDBAIBBCCeWLRusNLb--vmWOkxm34qDjTMWkc 3utIhOMoMwKDqbgQg2iiKWySZrD-6c88HMZ6vhIHZPamChLlzGH eZ7pTS8jYCCD6jRWhlRB8c
ドラフトからははっきりとは読み取れなかったけどこのハッシュアルゴリズムはなんでもいいっぽい。キャッシュのためにACMEサーバが利用可能なアルゴリズムを制限しても良い、と書かれてる。なるほど。
▼TLS 1.2 is Frozen
こちらのツイートから。
『TLS 1.2 is Frozen』https://t.co/fJWHyI5vKi
— ゆき (@flano_yuki) 2023年5月17日
おぉ、Rich Salz先生。TLS1.2をフリーズして拡張の追加などはしないようにする提案#yuki_id
リンク先はこちら。
もうTLS1.3が出て5年近く経つので、今更TLS1.2でもないか。
拡張の追加だけでなく、アルゴリズムも追加しない、ということなので、最近検討されているTLS_AEGIS_256_SHA384とかもTLS1.2では使えなさそう？あれはそもそも鍵交換アルゴリズムの指定のないTLS1.3用スイートだから無理か...。
▼ECDHE+Kyber
こちらのツイートから。
『Post-quantum hybrid ECDHE-Kyber Key Agreement for TLSv1.3』https://t.co/WvJ0WackNe#yuki_id
— ゆき (@flano_yuki) 2023年5月18日
リンク先はこちら。
supported_groupにSecP256r1Kyber768Draft00とかを使うらしい。ECDHEとKyberそれぞれの鍵交換を同時に行なって、得られた結果をくっつけて秘密情報とするとか。
▼Cloudflare UniversalSSLの障害
こちらのツイートから。
【Cloudflare UniversalSSLに関連】
— testtlnls (@testtlnls) 2023年5月18日
数日前からUniversalSSLでGTS Root R4にチェーンする証明書が使われることがあるようです。
GTS Root R4にはクロス署名がないらしく、古いOSで証明書エラーになるようです。
Googleのリポジトリによると、GTS Root R4は2012年11月の発行なので、それ以前のOSがダメそう？
現在は解消している様子。
CloudflareのUniversal SSLで普及率が低い（GTS CA 2P2発行の）証明書が使われることがあった問題ですが，
— testtlnls (@testtlnls) 2023年5月21日
昨日からGTS CA 2P2をUniversal SSL証明書の発行に使わなくなったようです．
当該証明書はAndroid 9以前で証明書エラーになります．
詳しくは「Issue with SSL in mobile Chrome」で検索 pic.twitter.com/mP2zqYb9Rh
Android 9って2018年リリースなのにGTS Root R4のルート証明書入ってないんだ...意外。
▼CloudflareでmTLS
こちらのツイートから。
Cloudflare for SaaS で SaaS エンドユーザーのお客様ドメインでもクライアント証明書による認証ポリシー（mTLS）を設定できるようになります。現在 Beta で Enterprise Plan で利用可能になる予定です。https://t.co/CRYJtUhZ9q
— kyhayama (@kyhayama) 2022年4月4日
リンク先はこちら。
先週はFastlyがmTLSやってたし、最近流行ってるのかしら。
▼技術書典14
こちらのツイートから。
> ページ数: 210
— 竹原涼 (@takehara3586) 2023年5月18日
すごいページ数。期待大
プロトコル研究所 | 詳解QUICクライアント接続編 #技術書典 https://t.co/Xdqh65IIUP
オフラインでも開催された技術書典14でもいくつかプロトコルや暗号関連の本が出ていそう。買わなきゃ...。
オンライン開催は6/4(日)までとのこと。
▼X.509証明書のnoRevAvail拡張
こちらのツイートから。
『No Revocation Available for Short-lived X.509 Certificates』https://t.co/dN8ecxVL5w
— ゆき (@flano_yuki) 2023年5月19日
よむぞ
R. Housleyせんせいと、デジサートのおおくぼ先生が共著ではいってる#yuki_id
リンク先はこちら。
失効情報の不要な短命な証明書が流行ってるから、失効情報がないことを識別できるようにしようぜって提案っぽい。
元々はX.509を定めた国連期間ITU-Tが2000年に定めた仕様に含まれているとか。あっちこっちに仕様があって分かりづらい...。
Firefoxは既に有効期限が短くなった証明書の失効情報を無視するフラグを持っている様子。
この手の、ブラウザ独自の証明書失効確認なにやってるのか全然知らないんだよなあ
— ゆき (@flano_yuki) 2023年5月20日
> Mozilla added code to ignore OCSP extensions for certificates with lifetimes less than some small number of days. https://t.co/hiOgNmhEJ6
Chrome Root Program的には証明書の有効期間は90日にしていく方針らしいし、失効情報って今後ちゃんと使われるんだろうか...。
[まとめ]
最近なんだかニュースを集めすぎている気がする...まとめきれない...というわけで今週は暗認本はおやすみ。
