2024年9月9日~2024年9月15日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第173回分。
[Chrome: Network Time for Certificate Verification]
こちらのツイートから。
『Chromeで、サーバ証明書検証時にネットワークから取得した時刻を使う』https://t.co/VFiJprJg8X
— ゆき (@flano_yuki) 2024年9月13日
ブログ書いた。#asnokaze
『Root Causes of Chrome HTTPS Certificate Errors』https://t.co/IWpJ6s9mNq
— ゆき (@flano_yuki) 2024年9月9日
2017の論文だけど、Chromeでの証明書エラーの割合。
Client側のエラーとして時刻設定の問題がそれなりにあって、未だに課題なんだろうなって pic.twitter.com/K9Vg43bVTc
リンク先はこちら。
2017年の論文ではWindows上で3割を超える証明書エラーが時刻設定の問題に起因しているようだ。Androidの方の「不十分な中間証明書」も気になるが...。
時刻のずれ方としては、24時間以上遅れているものが多いようだ。酷いものだと3ヶ月近く遅れているケースもあるという。
原因については正確な理由は不明だが、ソフトウェアライセンスを誤魔化そうとして時刻をずらしているケースがあるのでは、と書かれている。マルウェアによる時刻操作の可能性も指摘されているが、マルウェアによる時刻操作はあまり研究されていないらしい(2017年当時)。
クライアントの時刻が遅れているケースもあるので、証明書を更新して有効期間が新しいものをデプロイすると、クライアント側でまだ開始日を迎えていない扱いになってエラーになるケースとかもあるらしい。
証明書の有効期間を90日にしようとしているChromeにとって、この機能は重要な役割を果たしそう。
ただ、Canaryだからかまだちゃんと動かなさそう?
Chrome Canaryに、証明書検証時にネットワークから取得した時刻を使うヤツ 来てた。
— ゆき (@flano_yuki) 2024年9月12日
有効にすると.... Chrome 起動しなくなる.... Canaryだからね pic.twitter.com/z02MDb8RAN
[その他のニュース]
▼QUIC is not Quick Enough over Fast Internet
こちらのツイートから。
プレゼンを観た。肌感覚と合致してる。無線とか接続が不安定なシチュエーションだとQUICの方が早いけど、有線の理想的な環境だとTCP+HTTP/2の方が早い。
— えもんが🍁♨️ (@emolga587) 2024年9月8日
国際専用線やクラウドのリージョン間通信でも、TCPかQUICかではなくBBRかCUBICかみたいな輻輳制御アルゴリズムの方が寄与する部分が多い印象 https://t.co/uGKHSwDbfb
リンク先はこちら。
https://dl.acm.org/doi/10.1145/3589334.3645323
QUICだとパケット数が増えたりローカルでの処理時間が伸びたりしてるのが原因と言われている様子。アプリケーションに近いところのプロトコルよりもそもそもインターネットが速いかどうかが大事っぽい。
この時のTCPで使われたTLSは1.3だったのかとか、同じ鍵交換や暗号のアルゴリズムが使われたのかどうかとかが気になる。
▼ACM IMC 2024
こちらのツイートから。
『ACM IMC 2024』気になる
— ゆき (@flano_yuki) 2024年9月9日
- Mutual TLS: Another Layer of Security or Not Really?
- Replication: “Taking a long look at QUIC"
- A First Look at Related Website Sets
- Deciphering the Digital Veil: Exploring the Ecosystem of DNS HTTPS Resource Recordshttps://t.co/ptyIBucSXc
リンク先はこちら。
ACM Internet Measurement Conference 2024がマドリードで11月に開かれるらしい。Mutual TLSのセッション気になる。
ACMはAssociation for Computing Machineryの略で、会員になるとO'Reillyの本が読み放題になるやつ。
▼Palo Altoの次世代FWとPQC
こちらのツイートから。
量子コンピュータの性能の向上は、既存の公開鍵暗号基盤における暗号技術を危殆化させると言われています。こうした脅威の対策に向けて、弊社の次世代ファイアウォール製品は、昨年のPAN-OS 11.1から耐量子計算機暗号(PQC)への対応を開始しました。
— Palo Alto NetworksJP (@PaloAltoNtwksJP) 2024年9月10日
詳しくはこちら☟https://t.co/FGQs773EG3 pic.twitter.com/JhUuxD1le7
リンク先はこちら。
PQCが使われたTLSセッションも可視化できるらしい。耐量子VPN、知らなかったけどそういうのもあるのね。
▼TLS Key Share Predictionドラフト更新
TLSの鍵交換で利用する名前付きグループに関する情報をDNSを通じて配信するTLS Key Share Predictionのドラフトが更新されていた。
値がnon-emptyである点や、重複した値が許可されない点などが明記された。
▼HTTPS for Local Networks
こちらのツイートから。
『HTTPS for Local Networks』https://t.co/ElwflW0XT0
— ゆき (@flano_yuki) 2024年9月13日
おお!W3C TPACのBreakoutに httpslocal ばなしが揚げられている。懐かしい
リンク先はこちら。
W3Cのイベントで、一般的な認証局からの証明書を取得できない.localや.homeなどのドメインやプライベートIPなどを対象にしたHTTPS通信の実現方法についてのセッションがあるらしい。気になる。
同様の話題を扱うコミュニティグループが2023年まで存在していたが、閉鎖されてしまったとのこと。
▼ML-KEM in Chrome 131
こちらのツイートから。
How Chrome is planning on rolling on the final standardized version of Kyber / ML-KEM https://t.co/mk0J74iRlZ
— David Adrian (@davidcadrian) 2024年9月13日
It's pretty simple, we're just going to do a hard cut over from Kyber+X25519 to ML-KEM+X25519 in Chrome 131.
— David Adrian (@davidcadrian) 2024年9月13日
リンク先はこちら。
ML-KEMとして最終版が出たことで、Kyber時代との互換性がなくなっているらしい。そのため、supported_groupsの新しいコードポイントとしてSecP256r1MLKEM768(0x11EB)とX25519MLKEM768(0x11EC)が提案されており、2024年11月にリリース予定のChrome 131からハイブリッドKyberを廃止し、ML-KEMに切り替える予定とのこと。
これに先立ち、BoringSSLもML-KEMをサポートしていた。Adam Langley氏がコード書いてる...!
[おわりに]
コード書いて生きていきたいなあ...。