2023年10月2日～2023年10月8日に読んだ中で気になったニュースとメモ書き（TLSらじお*1第126回の原稿）です。
全文を公開している投銭スタイルです。
[Let's Encryptは詐欺?]
こちらのツイートから。
「発行者が「Let's Encrypt」ならまず詐欺なので用心しよう」
— Yurika (@EurekaBerry) 2023年10月4日
ちょっと過激な対策の提案に思えますね👀
https://t.co/XWOyhPss48
リンク先はこちら。
他にも、LEゴールドスポンサーの時雨堂さんはじめ、いろんな人がツイートしてたけど、過激というかなんというか。Chromeの鍵マーク無くなってるし。後日、Let's Encryptは詐欺という部分は訂正されたらしい。
とはいえ、セキュリティインジケータがわかりにくいというか、あまり役に立ってない問題はあるよなあ...。
https://t.co/l66QdJ8kAw にたくさん詐欺サイトあってすごいね～ https://t.co/vbrLNw5shE https://t.co/dutF7fwujD
— そらは (@sora_h) 2023年10月4日
[Cloudflare + ML-KEM]
こちらのツイートから。
Cloudflare からのアウトバウンド接続でポスト量子暗号 (X25519+KyberからML-KEMに名称変更予定) に対応。ロールアウト予定だが API で即時有効化も可能。ClientHelloサイズが大きく、HelloRetryRequest が必要。調査では0.34%が接続に失敗するため、業界全体での支援が必要https://t.co/MFmsCF9mGz
— kyhayama (@kyhayama) 2023年10月3日
リンク先はこちら。
よく分かってなかったけどFIPSのドラフトでX25519+Kyberの名前がML-KEM(Module-Lattice-Based Key Encapsulation Mechanism)にかわるらしい。なるほど。
ブラウザ-Cloudflare間だけじゃなくてCloudflare-オリジン間の通信もML-KEMをサポートし始めるとのこと。
HelloRetryRequestが必要になるのはサーバと鍵共有がうまくできなかった場合。HRRが発生すると、TLS1.2の時のように、1往復分やりとりが増えることになるので好ましくない。ということでChromeなど一部のブラウザはHRRを防ぐためにX25519とML-KEMの両方の鍵共有を同時に実行するらしい。なるほど。
[その他のニュース]
▼Wiresharkの使い方
こちらのツイートから。
わいわい。いいね。 / “Wireshark によるパケット解析講座 1: Wiresharkの表示列をカスタマイズする” https://t.co/udWoda2rGQ
— matsuu (@matsuu) 2023年10月1日
リンク先はこちら。
列のカスタマイズ、便利。ClientHelloのserver name拡張を列にできるの知らなかった。
▼Say an encrypted hello
こちらのツイートから。
Finally! 🥳https://t.co/VulWR7TEeb
— Dennis Jackson (@Dennis__Jackson) 2023年10月3日
リンク先はこちら。
FirefoxがEncrypted ClientHelloをサポートしたらしい。DoH (DNS over HTTPS)などのプライバシー技術と組み合わさって動作するとのこと。なるほど。
▼GlobalSignのOV証明書ACMEサポート
こちらのツイートから。
GlobalSignってOV証明書のACMEに対応してたんですね。ただ、どうやってValidationするのかが気になるなあ。
— Ichihara Hajime / 市原創 (@haj18) 2023年10月4日
初回発行時のValidationプロセスだけマニュアルで以降は裏でチェックしつつ更新処理を自動化するとか…？https://t.co/rbgJfy6t84
リンク先はこちら。
2023年3月からサポートしてるらしい。手続きがよくわからんしテストもしづらいし、使ってる人いるのかな...。
OVは無意味と言われていますし...。
はあ？ 別に問題ない。森永乳業が https://t.co/Lmc6vOP3n5 ドメインを推していくのならEV証明書買わずともDV証明書で何ら問題ない。（OVは無意味。）https://t.co/kI9FvnqzeZ
— Hiromitsu Takagi (@HiromitsuTakagi) 2018年6月5日
▼OpenSSLのGitHub Projects
こちらのツイートから。
🚧 Plan · Project Board https://t.co/y59nOaOuZN OpenSSL が GitHub Projects で色々見られるようにしてる。
— V (@voluntas) 2023年10月5日
リンク先はこちら。
いろんなイシューが並んでて面白い。
▼新プロトコルはTLS1.3で
こちらのツイートから。
New Protocols Must Require TLS 1.3https://t.co/LiVuuGJyuG
— ゆき (@flano_yuki) 2023年10月6日
新しいアプリケーションプロトコルではTLS 1.3を前提にしようてきな話し。IETF UTAへの提案。#yuki_id
リンク先はこちら。
あくまでTLSの話で、DTLSは関係ないよ、とのこと。DoT(DNS over TLS)のデフォルトはTLS1.2で、TLS1.3がオプションだが、今後このようなプロトコルが登場する場合には、逆転することになる。
そういえばIETF 116でTLS1.2を非推奨にし、基本TLS1.3にする話が出てた。その流れだろうか。
▼Practical Challenges with AES-GCM
こちらのツイートから。
Practical Challenges with AES-GCM and the need for a new mode and wide-block cipher https://t.co/r629SnuQdK
— Frank ⚡ (@jedisct1) 2023年10月6日
リンク先はこちらのPDF。
AWSの人がNISTで発表したっぽい？
AES-GCMがブロック暗号なので、同一キーで暗号化できるブロック数に制限がある話とか、キーや初期化ベクターの衝突の危険性がある話とかの問題をどう解決するか、ということで、Rijndael-256などの新しい暗号アルゴリズムや、AEGISやOCBといった新しい暗号利用モードを使うことになるらしい。AEGISってそういう文脈でもあったのか...。
[暗認本：25 ハッシュ関数]
引き続き、ニュース以外のメインコンテンツとして『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んでいく。
今週はChapter 5 認証から、セクション25をざっとまとめた。
- 指紋とハッシュ関数
- コンピュータの扱う膨大なデータに全て異なる識別子を割り当てる仕組み
- データはコピーできるので、ハッシュ関数単体では認証に使えないので他の技術と組み合わせる
- 詳細はセクション29 署名
- ハッシュ関数とは
- 誕生日パラドックス
- ハッシュ関数の歴史
- パスワードとハッシュ関数
- パスワードの安全な保存方法
- ファイルのパスワード暗号化
[まとめ]
HTTPSの絵本かあ...どういう話にするといいんだろう。HTTPS太郎がACMEだんごをもらって3通のDV証明書を...いや昔話じゃなくてもいいか。
技術書を絵本にするの、かなり良いと思うんだよな。まずは HTTPS の絵本が欲しい。
— V (@voluntas) 2023年10月8日
※以降に文章はありません。投銭スタイルです。
