2024年1月29日～2024年2月4日に読んだ中で気になったニュースとメモ書きです。社内勉強会TLSらじお第142回分。

[Encrypted Client Helloとコンプライアンス]

こちらのツイートから。

Your Firewalls and Proxies are about to be blind to real TLS destinations: Learn about Encrypted Client Hello https://t.co/TaV5sIwnKg
— /r/netsec (@_r_netsec) 2024年1月29日

リンク先はこちらのPDF。

SNIが平文なので危なくて〜というのは理解しているつもりだったが、ALPNのTLS拡張もクライアントがサポートするアプリケーションプロトコル情報を伝えており監視の面では重要、と書かれており勉強になった。確かになー。

金融系の業界ではECHがネットワークトラフィックの監視要件に影響する可能性があるとの指摘も。プライバシー的には必要な技術なんだろうけど、監視とかは大変そう...。

関連して。

NCCoEは、SP 1800-37 "Addressing Visibility Challenges with TLS 1.3 within the Enterprise"のDraftに対するパブコメが募集されていて、期間は 2024年4月1日だよっ✨

Addressing Visibility Challenges with TLS 1.3 within the Enterprise,https://t.co/f7G4wOvuwQ
— 菅野哲 / GMOイエラエ取締役CTO (@satorukanno) 2024年2月1日

リンク先はこちら。

www.nccoe.nist.gov

NISTがTLS1.3を利用していても企業内で適切な監視を行うためのアプローチやツールを紹介するSP（Special Publication）のドラフトらしい。F5社やMira Security社のツールなどが紹介されていた。

こちらのツイートから。

Cryptography & Security Newsletter is out! Issue 109:
- CA/Browser Forum Adopts CAA for S/MIME Certificates
- Short Newshttps://t.co/novDn7mBQe pic.twitter.com/EoQlNaV9RL
— Feisty Duck (@feistyduck) 2024年2月1日

リンク先はこちら。

www.feistyduck.com

トップニュースはS/MIME証明書に関するCAAレコードの採用が決定された。2024年1月にCA/B Forumで投票があったらしい。仕様を定めたRFC 9495が強制力を持つ形になる。後述の暗認本パートにも書かれているとおり、S/MIME自体はあまり使われていないので、ニュースの中ではCAAレコードでS/MIME証明書の発行を無効化するのが良いのでは、と提案されている。
CAAが最初にRFCになったのは2013のことで、CA/B Forumがサーバー証明書にCAAを採用するまでに4年かかった、と書かれていた。そんなに...。

気になったショートニュースは以下の通り。

アリスとボブの歴史がhttpsではなくhttpで提供されてるのちょっと面白い。

[その他のニュース]

▼AAC '24

こちらのツイートから。

📢📢📢 We are thrilled to unveil the AAC workshop program!

Excited to have Robert Merget (@ic0nz1) give our second Keynote! He will join us with a captivating talk on the security of the TLS protocol in practice.

All infos at https://t.co/J596rczyZ4

Stay tuned & see you in AD!
— AAC '24 (@AAC_Workshop) 2024年1月30日

リンク先はこちら。

aac-24.tii.ae

非対称暗号に関するワークショップが3月に開かれるらしい。招待講演の「Hard-Hat Cryptanalysis - Drilling Down into Real-world TLS Protocol Failures」というのが気になる。

▼ロシアのインターネット障害

こちらのツイートから。

ロシアのドメイン.ru及び.рф以下のインターネットが1/30に4時間近くに渡り停止。DNSSEC署名の問題。ロシアのデジタル省から復旧報。 https://t.co/PNUJE9P2RA
— kokumօtօ (@__kokumoto) 2024年2月1日

リンク先はこちら。

securityboulevard.com

DNSSECの署名が正しくないために障害が発生した、とされている。

▼ISUCONの証明書更新スクリプト

こちらのツイートから。

ISUCON 過去問を解こうとすると、TLS 証明書の有効期限が切れててブラウザが怒ってくるのでダルいというのがあるあるなんですが、最近 ISUCON 9 予選の過去問に追加されたこのスクリプトは賢いなと思いました。https://t.co/UCqXoPxjhm pic.twitter.com/ITbjhSQzsa
— KOBA789 (@KOBA789) 2024年2月3日

証明書をメンテしてるのは私ですが、このスクリプトを入れてくれたのは catatsuy さんです。活用されてて嬉しい。
— KOBA789 (@KOBA789) 2024年2月3日

リンク先はこちら。

github.com

ACMEとか使ってるのか？と思ったけどそうじゃなくて定期的に更新されてる証明書を取ってくる感じになっていた。なるほど。

[暗認本：41 メール]

『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』より、Chapter 8 ネットワークセキュリティのセクション41をまとめた。

SMTPとPOP3
- Simple Mail Transfer Protocol(RFC 821, 1982年/RFC 5321 2008年)
- Post Office Protocol version 3
- Internet Message Access Protocol version 4
- どれも平文。改善したAutomatic POPは2007年深刻な脆弱性発見。
- STARTTLSは途中で暗号化、不完全
- TLSを組み合わせたSMTPs、POP3s、IMAP4s
  - クライアントとメールサーバ間のみ。
  - メールサーバ間は一般に暗号化されない
  - 受信者がSMTPsを使う保証はない
S/MIME
- 送信者と受信者の完全な安全性にはS/MIMEが必要
- 多目的インターネットメール拡張/Multiporpose Internet Mail Extension
- MIMEに秘匿性と完全性を提供する規格がSecure MIME
  - 秘匿性：公開鍵暗号
  - 完全性＋否認防止：署名(添付ファイルsmime.p7s)
- 事前に相手の公開鍵を入手する必要がありあまり普及していない
Webメール
- Yahoo!メール、Gmail、Outlook.comなど
- 原理的にサービス提供者は中身を閲覧可能、S/MIMEとは相性が悪い
- E2E暗号化を提供するメールサービスもある：ProtonMail、Tutanota
- LINE、Siggnal、WhatsApp、iMessageなどもE2E暗号化を導入。Messaging Layer Securityとして標準化（RFC 9420、2023年）

[まとめ]

もう半年くらい経ったし、そろそろツイートって書くのやめた方がいいのかしら...。

ランキング参加中

プログラミング

kdnakt blog

hello there.

今週気になったTLS関連のニュース

[Encrypted Client Helloとコンプライアンス]