先週に続き、2022年3月21日~3月27日に読んだ中で気になったニュースとメモ書き(TLSらじお第50回の前半用原稿)です。
[SSL/TLS証明書の有効期限]
いまだにSSL証明書、と呼んでしまう...それは良いとして、本題の有効期限。
Scott Helme氏の以下のツイートより。
Both Google and Apple will require 3 SCTs for certs with a lifetime > 180 days and remain at 2 SCTs for certs <= 180 days. Is this an indicator that the next certificate lifetime restriction will be a push to 6 months?
— Scott Helme (@Scott_Helme) 2022年3月21日
[1] https://t.co/w5pqeSDYnj
[2] https://t.co/4JMjVxD29b
GoogleとAppleの規定をベースに、次の証明書有効期限が180日になるのではないか、との推測。
証明書の有効期限は、業界団体のCA/B Forumが発行しているBaseline Requirements*1で規定されている。Baseline Requirementsは頻繁に更新されており、2020年8月のバージョン1.7.1では証明書の有効期限を398日以内にすることと定められた。
過去の推移をBaseline Requirementsの記載を元にまとめると以下のようになる*2。
- 2015年3月31日以前:60ヶ月以内
- 2015年4月1日:39ヶ月以内(一部例外あり*3)
- 2016年6月30日:39ヶ月以内(例外なし)
- 2018年3月1日:825日以内
- 2020年9月1日:398日以内
今は1年に1回の更新作業だから手作業でもなんとかなる気がするが、6ヶ月とか3ヶ月とかになる未来があるとすれば、certbotとかAWS ACMで自動更新に対応しないと大変そう。
[DNSとTLS:HTTPS, TLSAレコード]
DNSだからHTTPSとは直接関係ないかな?と思ったけど、設定値にalpn(Application-Layer Protocol Negotiation)*4とかech(Encrypted ClientHello)とかがあって、接続パラメータをDNSレベルでやりとりできるらしい。すごい。
こんなツイートも。
TLS Client Authentication via DANE TLSA recordshttps://t.co/HXGGaHVUK3
— ゆき (@flano_yuki) 2022年3月24日
WG draftになってた。追ってなかった#yuki_id
DANEというのはDNS-Based Authentication of Named Entitiesの略らしい。HTTPじゃなくてSMTP関係の仕組みらしい*5。
[Go 1.18とOCSP署名方式]
こちらのツイートより。
(Yes, it's ludicrous that CAs are still signing OCSP responses with SHA-1, six years after I demonstrated how susceptible OCSP is to hash collision attacks: https://t.co/oRzFdt13fs. This unsafe practice will finally be banned as of June 1: https://t.co/fb0sv0JYTL.)
— Andrew Ayer (@__agwa) 2022年3月23日
OCSPレスポンスはRFC 2560で定められている通り、CAまたはその代理人の鍵で署名されている。OCSPレスポンスへの署名方式としてBaseline Requirementsで2022年6月1日以降はSHA-1を禁止する、とされた。ただ、OCSPと同じく証明書の失効情報を提供するCRLもSHA-1で署名されるが、こちらは禁止されていないらしい*6。
2022年3月15日にリリースされたGo 1.18では、誤ってSHA-1による署名全般が利用不可となってしまった結果IstioやKubernetesで影響があったらしく、Go 1.18.1で修正見込みとのこと。
[その他のニュース]
▼AWSプライベートCAのアップデート
名前制約はまあわかるとして、拡張子ってなんだ?と思ったら、TLSらじお第47回でチェックしたBulletproof TLS Newsletter #86のトップニュースになっていた、EUのQualified Website Authentication Certificates (QWACs)で利用される適格証明書拡張子というのがあるらしい。
Bulletproof TLS Newsletter #86の文中でも、また、そこで引用されていたHelme氏の以下のブログでも、QWACsの有効性は疑問視されているのに、AWSあたりはこういうのにちゃんとついていこうとするんだな...。
▼IETF 113 Vienna
こちらのツイートより。
気になるテーマは、これですかね〜。
— 菅野 哲 (Satoru Kanno) (@satorukanno) 2022年3月23日
・Hybrid key exchange in TLS 1.3https://t.co/AcwpnPAkdV
・Deprecating Obsolete Key Exchange Methods in TLS https://t.co/CRcyA5solF
・AuthKEM https://t.co/gzy5HN3tBV
lamps WGでの出来事を見るにPQCの利用に向けてIETFの中の人が準備しはじめたっ!
— 菅野 哲 (Satoru Kanno) (@satorukanno) 2022年3月25日
・Quantum-safe Keyshttps://t.co/Hqdr6wEVXG
・NIST PQC KEM public keys in certificateshttps://t.co/7GzhlfZiih
・PQ KEMs in CMShttps://t.co/RoG4enz1Gw
・Composite Keyshttps://t.co/M8n76SA56o
ウィーンにて、RFCの標準化を進めているIETFのミーティングが開かれているらしい。TLSもまだまだ変わりそう。
▼BoringSSL
こちらのツイートより。
Open Quantum Safe OpenSSL/BoringSSL (fork)
— ゆき (@flano_yuki) 2022年3月23日
- https://t.co/O8DpCKnV7M
- https://t.co/FsG5egF8LQ
知らなかった
GoogleがOpenSSLをフォークして、プロトタイプ的に耐量子暗号を組み込んでいるらしい。
▼Java18リリース
こちらのツイートより。
JDK 18 has shipped! Check out my latest blog, where I have compiled a list of the most interesting and useful security features and enhancements in this release: https://t.co/C53DtFdNWF #jdk18 #openjdk #java #security
— Sean Mullan (@seanjmullan) 2022年3月23日
cacertsストアのフォーマットが標準的でないJKSから、標準的なPKCS12に変更になったり、いくつかのルート証明書が削除されたりしたらしい。
▼SSLPulseの更新状況
こちらのツイートより。
SSL Pulseが2022年1月4日分から更新されない状況が続いており、サポートで質問してみたらSSL Labsの担当が代わったので新しい担当に確認中との事でした、、、
— kjur セキュリティ IT 開発の私的情報収集用+少しつぶやき (@kjur) 2022年3月26日
SSL Pulseは以下のサイトのこと。『プロフェッショナルSSL/TLS』の原著者であるIvan Ristić氏のプロジェクトである。
SSL ほぼ毎月のSSL/TLS利用状況に関する調査結果が公開されているが、月毎にしか閲覧できないためkjurさんがデータの推移を閲覧できるようにしてくれている。最近だと、2021年11月にTLS1.0/TLS1.1の利用率がグッと減ったのが分かりやすかった。
[まとめ]
まとめのフリをした雑なコメント。
やっぱりDNSとかSMTPとか、周辺のプロトコルも勉強しないとダメかしら...なんもわからん...。
EUのQWACsの話はともかく、証明書の有効期限の話は仕事に直結しそうなので行方が気になる。IETFの議論とか耐量子暗号の話が仕事に影響するのって何年後だろうか...。
そういえばJavaは自分のメイン言語の一つなのに、Java 18の新機能とか何も知らないや。反省。
*1:2022年3月末現在のBaseline Requirements最新バージョンは2022年1月26日に発行されたバージョン1.8.2。
*2:この辺の話は以下の記事に詳しい。
*3:Baseline Requirements 1.2.3の記載によれば、既に利用されていて、置き換えが難しい場合などは、60ヶ月までの有効期限が許可された。
*4:これについては昨年末にALPACA攻撃に関する記事を書いた。
*5:すっかり忘れていたけど、プロフェッショナルSSL/TLSでも80ページでちらっと触れられていた。
*6:CRLの署名といえば、2021年にはLet's Encryptの古いルート証明書によるCRLへの署名が話題となった。