先週に続き、2022年5月2日～5月8日に読んだ中で気になったニュースとメモ書き（TLSらじお第55回の前半用原稿）です。
[ChromeとGoogle CTログ]
Andrew Ayer氏の一連のツイートから。
If your website's SSL certificate was issued in 2020, it may have stopped working in Chrome today (with the error NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED). Fix is to get a new certificate from your CA.
— Andrew Ayer (@__agwa) 2022年5月3日
Use this tool to check if your site is affected: https://t.co/0u6aTH9y31
Background: Chrome requires all certificates to be published in at least one active (non-retired) #CertificateTransparency log. For various reasons, logs are occasionally shut down/retired. If every log that a certificate is logged to is retired, the cert stops working. 2/n
— Andrew Ayer (@__agwa) 2022年5月3日
Many non-Google logs have been retired over the years, but until recently Chrome required that certs also be logged to a Google-operated log. Thus, retiring a log never caused certs to break: you could always count on the cert to be in an active Google log. Until yesterday. 3/n
— Andrew Ayer (@__agwa) 2022年5月3日
Yesterday, Google-operated logs were retired for the first time: https://t.co/1VECFdKAmM
— Andrew Ayer (@__agwa) 2022年5月3日
The retired logs (Icarus, Rocketeer, Pilot, and Skydiver) are legacy logs which have been superseded by Argon and Xenon. 4/n
The graceful shutdown of these logs began in 2020. One by one, Icarus, Rocketeer, Pilot, and Skydiver were reconfigured to reject most new certificate submissions. Eventually, they would contain only expired certificates, allowing them to be retired without causing breakage. 5/n
— Andrew Ayer (@__agwa) 2022年5月3日
The last log was reconfigured on June 10, 2020: https://t.co/4DN7c92tYn
— Andrew Ayer (@__agwa) 2022年5月3日
At the time, the longest certificate lifetime was 825 days. Thus, on Sep 13, 2022, it would be safe to retire these logs. 6/n
But Chrome retired these logs on May 1. There are still unexpired certs in Skydiver, Rocketeer, and Pilot. Any cert logged to one of these logs plus one of the retired non-Google logs (DigiCert 1 or 2) is now broken. 7/7
— Andrew Ayer (@__agwa) 2022年5月3日
Google ChromeでTLS接続するには、証明書がアクティブなCT（Certificate Transparency、証明書の透明性）ログに登録されている必要がある。しかし2022年5月1日をもって、Chrome 101以降でGoogleが運営するいくつかのCTログが廃止されてしまったため、サイトに正常に接続できなくなる可能性がある、ということらしい。
以下のサイトでドメインを入力すると、問題の有無を確認できる。
該当のCTログには2020年から新規登録をしていなかったので影響が少ないと思われていたが、実際には、当時2年間の有効期限のある証明書のCTログを登録して利用していたケースがあり、影響範囲が大きかったためか、5月3日にCTログの廃止は取りやめられたらしい。さっさと移行せい、とのこと。
Update: these logs have been un-retired.
— Andrew Ayer (@__agwa) 2022年5月3日
This is not yet reflected in the JSON log list published by Google, but can be seen in the protobuf file that is downloaded by Chrome clients several times a day. Once your client downloads the latest file, the errors should stop.
Chrome's official announcement of the un-retirement: https://t.co/E2WgajkM6v
— Andrew Ayer (@__agwa) 2022年5月3日
Chrome still plans to retire these logs in the "near future" says sites using impacted certs should replace them ASAP.
GoogleのCTログといえば、下記CTログの検索ページが2022年5月15日にサービス終了する件とは無関係なのだろうか。
CTに関する変更を追いかけるには、メーリングリストやバグトラッカーを追いかけると良いらしい。
How do I keep track of the dizzying number of #CertificateTransparency changes?
— Andrew Ayer (@__agwa) 2022年5月4日
✅Subscribed to ct-policy mailing list
✅Subscribed to Chromium bug tracker CT component
✅Automatically ingest JSON log lists from Apple and Chrome
🔜Automatically ingest Chrome protobuf log lists
CTログこんなにたくさんあったのね...。
有償サービスとして、CTログのモニタリングをしてくれるらしい。
[CTログの悪用]
こちらの記事から。
CTログの登録を高速でチェックして、初期設定が完了していないWordPressのサイトを攻撃する、というのが数年前から発生しているらしい。
ログ登録して1分...速過ぎる。
ちなみにLet's Encryptのフォーラムでは、証明書取得から1分で/wp-include/.query.phpが生成された(statで生成日時を確認済)との報告もあったので、速攻でやられる可能性があります。
— matsuu序二段 (@matsuu) 2022年5月7日
こういう攻撃があるとすると、CTを無効化するのもありなのかもしれない、と思う。
しかし、前述のツイートにあるとおり、Chromeでアクセスする場合には、証明書が1つ以上のCTログに登録されている必要があるため、無効化するにもよくよくサイトの要件を考慮する必要がある。
Background: Chrome requires all certificates to be published in at least one active (non-retired) #CertificateTransparency log. For various reasons, logs are occasionally shut down/retired. If every log that a certificate is logged to is retired, the cert stops working. 2/n
— Andrew Ayer (@__agwa) 2022年5月3日
[Alexaサービス廃止]
こちらのツイートから。
うぉ〜〜〜。おれたちのAlexa Top Millionが2022/5/1でついにリタイアしたみたい😭今までありがとう！https://t.co/3aNAdFaOtk
— Hitomi Kimura (@hitok_) 2022年5月2日
Alexaと言っても、音声アシスタントではない。
『プロフェッショナルSSL/TLS』でたびたび脆弱性の影響範囲について言及する際に登場していたAlexaがサービス停止してしまった。
https://www.alexa.com/topsites
それわかんないよね！ここでdomaintoolsがどうしよかなっていくつか代替挙げてるの教えてもらったよ！https://t.co/fWVgtfXUyk
— Hitomi Kimura (@hitok_) 2022年5月2日
domaintoolsによると、The Majestic Million、The Cisco Umbrella 1 Million top domains、Netcraftあたりが代替候補のようだ。
[その他のニュース]
▼ExtraReplica脆弱性
こちらのツイートから。
Friends don’t let friends use mTLS.
— Ryan Sleevi (@sleevi_) 2022年5月2日
That’s it. Short rant. The state of verifying certs is mostly garbage outside browsers.
Meanwhile, in IETF LAMPS, folks are trying to add way more (broken and unnecessary) complexity for PQ and you just know it’ll be fine… https://t.co/1kpRasyinm
リンク先はこちら。
AzureのPostgreSQLデータベース接続時のクライアント認証において、証明書のCN（Common Name）検証時の正規表現に問題があったため、replication.eee03a2acfe6.database.azure.com.wiz-research.comのようなCNの証明書を取得するだけで認証をパスできてしまうらしい。正規表現気をつけなきゃ...。
▼OpenSSLセキュリティアドバイザリ（2022/05/03）
こちらのツイートから。
CVE-2022-1473 The OPENSSL_LH_flush() function, which empties a hash table, contains a bug that breaks reuse of the memory occuppied by the removed hash table entries. This function is used when decoding certificates or keys. If a long lived proces... https://t.co/QEM7Tb1u3m
— CVE (@CVEnew) 2022年5月3日
計4件の脆弱性が修正されている。RC4とかもうほとんど使われてないだろうからあまり影響はなさそう。
https://www.openssl.org/news/secadv/20220503.txt
▼証明書デプロイエラー
ハンバーグでもテイクアウトしようかな、と思って2022年5月4日にwww.sengokuga.comにアクセスしたら証明書のエラーが。
secure cmsというのはこれっぽい。
CMSの利用者側の問題だろうか、それとも運用側の問題だろうか。運用側の問題だとしたら、高水準セキュリティとは...と言いたくなる。
2022年5月6日に解消された模様。
▼TLStorm 2.0
こちらの記事から。
2022年3月14日のニュースで取り上げたTLStormに類似の脆弱性が、別のデバイスでも見つかったらしい。詳細はこちらのブログ記事に。
▼ECDSA in Go 1.19
こちらのツイートから。
go 1.19 で ecdsa 関連が早くなるのか。
— V (@voluntas) 2022年5月5日
One last CL for Go 1.19... making the fiat-crypto backend 4x faster at fixed-base scalar multiplication through a simple precomputation, which makes P-224/P-384/P-521 ECDSA 1.5x–3x faster 💁♂️https://t.co/MNl4EDEuze pic.twitter.com/sj3BKG6b4Y
— Filippo Valsorda (@FiloSottile) 2022年5月4日
先週のニュースでも取り上げた、ECDSA関連の話題が追加。
変更されたソースコードを見ると、二重になっていたfor文が解消されていたりして、確かに速くなっていそうではある。
▼X25519鍵交換ハンズオン
こちらのツイートから。
I wrote a site to help explain how X25519 key exchange works.
— 𝔐𝔦𝔠𝔥𝔞𝔢𝔩 𝔇𝔯𝔦𝔰𝔠𝔬𝔩𝔩 (@xargsnotbombs) 2022年5月4日
Did it help you understand? Let me know what you think!https://t.co/e3PugvViQk
TLS1.2とかTLS1.3とかQUICのハンドシェイクをバイト単位で視覚化してくれたのと同じ人。今回は視覚化というよりはハンズオン形式で、Curve25519楕円曲線の公開鍵の計算を説明してくれている。
▼量子コンピュータ大統領令
こちらのツイートから。
ここで言う新暗号技術はPQCなので後押しするのはよいとして、「量子コンピューターの計算能力は近年急速に発展し、今後10年ほどの間に、通信の安全が脅かされる水準まで向上すると予測」とな！？ マジか
— 菅野 哲 (Satoru Kanno) (@satorukanno) 2022年5月6日
--
米、新暗号技術へ大統領令 量子計算機の発展見据え: 日本経済新聞 https://t.co/d0BUw8lelE
国のトップレベルでこういう決断ができるのは強い。
▼Golangで作るTLS1.3
こちらのツイートから。
ほぼGWを溶かした怪作が広まって欲しい😚 https://t.co/5OGpnSYtQN
— satoken@飲フラ (@ken5owata) 2022年5月8日
少し前にTLS1.2を自作されていた方。
golangで作るTLS1.2プロトコル(ECDHE&クライアント認証編)
TLS1.3、いまだにちゃんと理解できていないのでなんとか年内に頑張りたい...。この記事を読んでCertificateVerifyとかも変わってるんだなーというぼんやりとした理解を得られた。
[まとめ]
今週はなんだかCTログ周りがきな臭い感じ...。
