2022年11月28日～12月4日に読んだ中で気になったニュースとメモ書き（TLSらじお第83回の前半用原稿）です。
[TLSの安全利用推奨事項]
こちらのツイートから。
RFC 9325でた！
— ゆき (@flano_yuki) 2022年11月30日
TLSとDTLSの安全に使う推奨事項 https://t.co/VdpdvT1F8O
リンク先はこちら。
2015年に策定されたRFC 7525がTLS1.2ベースだったので、TLS1.3ベースになったということらしい。TLS1.2に関する記述は少なくなっていて、TLS1.3への移行を推奨する、とある。
SNI絶対使えよとか、ALPACA攻撃があるからALPN使えよとか、RSA鍵交換はあかんよとか、内容としては目新しいものは少ないが、脆弱性のあるポイントをまとめてくれているので
合わせてRFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for TLSとRFC 6066: Transport Layer Security (TLS) Extensions: Extension Definitionsも更新されている。GCMはnonceの再利用が認証失敗の脆弱性につながるらしい。自分でGCMスイートの実装した時はnonceの使い方とかがよくわからなかったので年末にこの辺ちゃんと勉強したい...。
証明書の失効にも触れられていて、Let's Revokeとか知らない仕組みが出てたので、細かいところまで見なければ...。
[TLS1.2までのプライバシー問題]
こちらのツイートから。
というプライバシー問題があったのでTLS/1.3で対処されました https://t.co/ZR6JAWPtMz
— Kazuho Oku (@kazuho) 2022年11月29日
これ。Appleのプッシュ通知がクライアント証明書を使ってるんだけど、TLS/1.2だと証明書が平文で流れるので、クライアントの移動をネットワーク管理者が追うことが可能だった。あ、あの学生、あの部屋（のサブネット）に入ったな、とか https://t.co/bXqNYcuCuw
— Kazuho Oku (@kazuho) 2022年11月29日
プライバシー上の問題があるメタデータは他にも、
— Kazuho Oku (@kazuho) 2022年11月29日
* クライアントIPアドレス
* SNI
* TCPのシーケンス番号
とか色々あって、それぞれに対策技術（提案中のもの含む）が存在する
クライアント証明書も平文で送られるから、ネットワーク管理者には丸見えというのは、言われてみれば確かに...。
TLS1.3ではServerHello後のハンドシェイクメッセージが事前共有鍵から計算されたシークレット（client_handshake_traffic_secret）で暗号化されるので安心。
[Let's Encryptの年次レポート2022]
こちらのツイートから。
We're building a better Internet by providing free and easy-to-use TLS certs. Your generosity this giving Tuesday will help us continue all of the work that goes into this. Read more in our parent nonprofit's 2022 Annual Report, out today! https://t.co/iXbTPyTL4O
— Let's Encrypt (@letsencrypt) 2022年11月29日
レポートはこちら。
2022年は、平均で1日300万通、最大で1日3億通の証明書が発行されているとか。すごい。
証明書は発行したら終わりではなく、発行した証明書が利用されるたびにOCSPの通信が行われる可能性がある。そのインフラにRedisが投入され、秒間20万のOCSPリクエストをキャッシュして捌いているとのこと。
[その他のニュース]
▼ChromeのHTTPSページ閲覧時間
こちらのツイートから。
Hey, @estark37 I just noticed a nice little bump on % of HTTPS sessions in Chrome from August. I assume there is now some logic that rewrites HTTP URLs to HTTPS? pic.twitter.com/3iMdmvOmMj
— Ryan Hurst (@rmhrisk) 2022年11月28日
ChromeのHTTPS利用率が2022年8月ごろに急増したらしい。
ChromeのマネージャのEmily Stark氏によると原因は不明で、統計上の問題があるかもしれない、とのこと。
I don't. it's a little suspicious that it's a uniform uptick across platforms and not mirrored in the % of pages loaded graph. a little worried it's a bug or metrics artifact or something...
— Emily Stark (@estark37) 2022年8月30日
元ネタのグラフはこちらのサイト。
▼CAAレコードのissuemailプロパティ提案
こちらのツイートから。
Certification Authority Authorization (CAA) Processing for Email Addresseshttps://t.co/NMYrJqt2rt
— ゆき (@flano_yuki) 2022年11月28日
DigiCertの方の提案。CAAレコードにissuemailプロパティを追加する。メールアドレスの証明って詳しくないから流れわからないな...#yuki_id
リンク先はこちら。
メールアドレスを証明する証明書ってなんだろう...と思ったけどこの間のOpenSSLの脆弱性の原因になったsubjectAltNameにrfc822Name（メールアドレス）を設定できるやつだろうか。
確認してみたら銀行から来たメールの署名に使われていた証明書でrfc822Nameが使われていた（subjectNameはCNがMUFG Bank, Ltd.で普通だった。）。なるほど。
▼Yandexのロシア離脱
こちらのツイートから。
Yandexがロシアから離脱...😲
— Autumn Good (@autumn_good_35) 2022年11月28日
Yandex N.V. provides strategic update on potential changes to the group’s corporate structurehttps://t.co/PXaVsYmqKH
リンク先はこちら。
Yandexといえば、2022年3月ごろにロシアが経済制裁回避のために新CAを設立した際に、同CAのルート証明書を受け入れたブラウザを提供していたのが記憶に新しい。オランダに親会社があったのか...。
検索と広告については売却される予定とのことなので、ブラウザについても売却されるのだろうか？
▼aws-lc
こちらのツイートから。
awslabs/aws-lc: AWS-LC is a general-purpose cryptographic library maintained by the AWS Cryptography team for AWS and their customers. It іs based on code from the Google BoringSSL project and the OpenSSL project. https://t.co/cbQv0uQSbR atode
— V (@voluntas) 2022年11月30日
リンク先はこちら。
OpenSSLとそれをもとにしたGoogleのBoringSSLのコードをもとに作られたAWS製暗号ライブラリとのこと。C言語用のlibcryptoとC++用のlibsslというライブラリがあるらしい。
どういう場面で使うんだろう...気になる。
[まとめ]
今週はニュースが多くて拾いきれなかったのでまた来週...。
