先週に続き、2022年4月4日~4月10日に読んだ中で気になったニュースとメモ書き(TLSらじお第52回の前半用原稿)です。
[ロシア情勢]
こちらのツイートから。
It seems that Certificate Authorities should now be able to start issuing certificates for Russian domains again! https://t.co/fu6NU2nk8D
— Scott Helme (@Scott_Helme) 2022年4月8日
アメリカの財務省がロシアへの経済制裁を部分的に解除し、インターネット通信サービス業の取引を認めた模様。Russian Trusted Root CAのような認証局が出てくるくらいなら、ロシア国内のメディアや反戦派が適切なコミュニケーションをとれるように、制裁を解除しよう、という流れらしい。
また、Russian Trusted Root CAについては、ロシア製のブラウザYandexでサポートされていると当初から発表されていたが、その実装に関する記事が書かれていた。
I wrote about Russia's new national certificate authority for sanctioned organizations and how it is supported in Yandex Browser. https://t.co/qGkg192K5O
— Koen Rouwhorst (@koenrh) 2022年4月8日
ChromeやFirefoxといった通常のブラウザのように、ルートトラストストアを持ってそこにRussian Trusted Root CAを追加するのではなく、暗号化されたルート証明書群をHTTP(HTTPSではなく)で取得して利用しているらしい。そのような挙動を仕込むにはバージョンアップが必要だと思うのだが、どうせバージョンアップするなら独自のルートトラストストアを持てばいいのに、どうしてこのような実装になっているのだろう?
[DNSとTLS:CAAレコード]
こちらのツイートから。
Plenty of domains use Certificate Authority Authorization CAA to restrict #TLS issuance to a CA. This is the first CA implementation I see allowing sites to restrict to an account at the CA as described in section 3 of rfc6844 https://t.co/YMBgobArZh pic.twitter.com/dVHVe3TSLU
— Cryptoki (@Cryptoki) 2022年4月6日
先々週もDNSの話題があった(HTTPSレコードとTLSAレコードの話)。
今回はCAAレコード。あるCAがドメインに対して証明書を発行できるかどうか、をDNSで制御できるらしい。
『プロフェッショナルSSL/TLS』(2017年7月版)では3.9節などで、証明書の発行に再してドメイン所有者の許可が求められないことがPKIの問題点、弱点の一つだと書かれていた。
素直にそれを信じていたのだが、2017年9月8日から事情が変わったようだ。認証局の業界団体であるCA/B Forumの規定が変わり、認証局による証明書発行の際はCAAレコードをチェックすることが義務付けられていた。
しかし、CAAレコードのチェックはあくまで義務として定められているだけで、技術的にドメイン所有者の許可なく証明書を発行することは可能なので、Russian Trusted Root CAのような認証局はやはり脅威と感じる。
続くScott Helme氏のツイートによると、36,000以上のドメインがCAAレコードを利用しているようだ。
Indeed there are many and growing! https://t.co/XjjKm4mreh
— Scott Helme (@Scott_Helme) 2022年4月6日
[その他のニュース]
▼PCI DSS v4.0リリース
こちらのツイートから。
New version of PCI DSS, Payment Card Industry Data Security Standard v4.0 (how card payments should be secured) was released March 31 https://t.co/WXfvUmVrQR
— Michal Špaček (@spazef0rze) 2022年4月4日
It says using Content Security Policy or Subresource Integrity or similar on payment pages will be required April 2025 pic.twitter.com/qVpkv6P9CX
PCI DSSはクレジットカード業界のセキュリティ基準である。
v3.2では2018年6月末までにSSLと初期のTLS*1(当時としてはTLS1.0/1.1)の使用を控えるようにという指示があったが、今回のv4.0では特にTLS関連で書き加えられている項目はなさそうだった。
▼RPKI
こちらのツイートから。
RPKI in 2021, by the numbers
— APNIC (@apnic) 2022年4月4日
6.3% ⬆️ routes in IPv4 routing table
9.9% ⬆️ valid routes
5.26% ⬇️ Not Found ROAs#RPKIweekhttps://t.co/eRPDyiFVyb pic.twitter.com/jTfpNO96Wn
RPKIウィークだったらしい。普段のWeb PKI以外に、RPKIという分野があるらしいことを初めて知った。
Resource PKIは、インターネットのルーティング基盤、特にボーダーゲートウェイプロトコルを保護するために設計されたフレームワークとのこと。
▼kTLS
こちらのツイートから。
Why doesn't Go's crypto/tls have kTLS integrations, despite me writing about it in 2017 (https://t.co/j0UK3cIoPa)?
— Filippo ${jndi:ldap://filippo.io/t} Valsorda (@FiloSottile) 2022年4月4日
This is what I am worried about: the TLS compatibility matrix is already multi-dimensional, kTLS adds kernel version and config.https://t.co/gHO78hv2vv pic.twitter.com/Ac2KzazW1o
kTLS...これも知らなかった用語。kernel TLSのことらしい。
パフォーマンスのための機能で、現在はレコード層の暗号化だけだが、最終的にはカーネルへTLSをオフロードしようとしているっぽい。
▼Google Cloud CA Service
こちらのツイートから。
📣 Google Cloud Certificate Authority Service (which has the ability to issue certificates for workloads reflecting their federated identities, even if the workloads are hosted on-premises or in other cloud) is now generally available.
— Google Cloud Tech (@GoogleCloudTech) 2022年4月4日
Learn more → https://t.co/kuZMBugtvN pic.twitter.com/9lJLjIefmv
先週話題にしたGCPのCA Serviceが一般利用可能になったらしい。他のクラウドサービスやオンプレミス用の証明書も発行できるとのこと。
▼耐量子暗号・ネットワークワークショップ
こちらのツイートから。
It is coming! The second edition of the Post-Quantum and Networks workshop is happening this 19th and 20th: https://t.co/Os8s1jw3V3 We will have a panel to talk about TLS and PQ with @agl__ @beurdouche @__caw__ and Panos Kampanakis pic.twitter.com/anQnMgT2lt
— sofía celi (@claucece) 2022年4月8日
Google, Amazon, Cloudflare, Mozillaの人も登壇するみたい。興味はあるけど理解できる気がしない...。
[まとめ]
いつかTLS1.2もPCI DSSで禁止される日が来るんだろうなあ...対応が大変そう。
DNS関連とかRPKIとかkTLSとか知らないワードがまだまだたくさん...精進します。