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

2023年7月31日～2023年8月6日に読んだ中で気になったニュースとメモ書き（TLSらじお*1第117回の原稿）です。
全文を公開している投銭スタイルです。

[WindowsのTLS1.0/1.1非推奨化]

リスナーからのお便り。こちらの記事から。

forest.watch.impress.co.jp

公式サイトはこちら。

learn.microsoft.com

TLS1.0/1.1を非推奨とするRFC 8996が出たのが2021年3月のこと。元々ブラウザでは無効化されているので、どれだけ効果があるのか不明だが、危険なので無い方がいいだろう。
でもサイド有効化するオプションがあるらしい。それでいいのか...？TLS関連のテストで利用するためくらいしか思いつかないが、「For organizations that need to use these versions」とあるが、どんな組織だろう。

[Bulletproof TLS Newsletter #103]

こちらのツイートから。

Bulletproof TLS Newsletter 103 is out! In this issue:
RFC 9420: Messaging Layer Security released after about five years in development. Why we need it, other standards and more.
And lots of short news from July. https://t.co/eLj4i0f3LW pic.twitter.com/IMC6A82H0E

— Feisty Duck (@feistyduck) 2023年7月27日

リンク先はこちら。

www.feistyduck.com

トップニュースはRFC 9420のMLS。メッセージングアプリケーションのE2E暗号化の話。現在Facebook MessengerやSkypeで事実上の標準として利用されているsignalプロトコルをさらに進化させるものらしい。TLSと似てるけど、そんなに関係はなさそう...?

ショートニュースで関係ありそうなものは以下（本ブログで取り上げていないもののみピックアップ）。

• ML：Mozillaもe-Tugra認証局のルート証明書を削除予定
  
  • Chromeから1ヶ月近く遅れているが、ESRには間に合ったのかな。
  • このサイトによると2023年8月6日時点ではまだe-Tugraは含まれていそう。
• 論文：CTログを利用したWebサイトへの攻撃
  • CTログでそもそもサイトがバレる。
  • 証明書の有効期限が切れてるサイトは脆弱性多し。
• Blog：XEAS-256-GCM/11
  • 謎のスイート。理論上はいろいろいいことがありそう？
• Podcast：AWS Certificate Managerのベストプラクティス
  • ACMのGM、Jonathan Kozolchyk氏がゲスト。
• ML：JavaのKDF API標準化
  • 2023年9月にリリース予定のJava 21の話っぽい 
• Blog：TLSレコードの断片化とGFWの検閲
  • 暗号化されないSNIの拡張を断片化すると、うまく検閲を回避できたとのこと。しかしそれを公表するとイタチごっこな気もする。

[CRYPTREC Report 2022]

こちらのツイートから。

CRYPTREC Report 2022が公開されていますので、ぜひご覧ください。
https://t.co/hzwAb6sQjv

— Ryoma Ito (@itorym) 2023年8月2日

リンク先はこちら。

www.cryptrec.go.jp

レポートは2023年7月26日公開。NISTのPQC関連の動向、最新の暗号解読技術論文の解説、素因数分解/楕円曲線上の離散対数計算の困難性の評価、などが掲載されている。

[その他のニュース]

▼ACME PQCネゴシエーションのドラフト

こちらのツイートから。

ACME PQC Algorithm Negotiationhttps://t.co/4LjIj71pRn#yuki_id

— ゆき (@flano_yuki) 2023年7月31日

リンク先はこちら。

www.ietf.org

ACMEでは、クライアントとサーバによる主要な暗号化アルゴリズムのサポートを前提としているが、PQCのために、ACMEクライアントがアルゴリズムを選択できるようにしようぜって話らしい。

▼3つのSCTの証明書

こちらのツイートから。

The cert has three SCTs, but Chrome's NetLog claims it has zero. pic.twitter.com/nb4GLJacVn

— 🎻 Eric Lawrence (@ericlaw) 2023年8月1日

A wild ERR_CERTIFICATE_TRANSPARENCY_REQUIRED appears.

— 🎻 Eric Lawrence (@ericlaw) 2023年8月1日

ChromeのログではSCTが認識されておらず、エラーになるとのこと。Chromeのバグだろうか？CTでは一般的に2つのSCTがあるケースが多いから、3つのケースが考慮されていなかった、とか？天下のGoogleがそんなことあるのか...意外。

▼OpenSSL announce bot停止

こちらのツイートから。

This bot is now retired.

Twitter has repeatedly changed/broken their API in the past months, I fixed it multiple times already but today it broke again.
The bot on Mastodon remains active (@opensslannounce@botsin.space).

— OpenSSL announce (@OpenSSLannounce) 2023年7月31日

無念...イーロンやりすぎだよ...。マストドンは動いてるらしい。初めてみようかな...?

▼Let's EncryptのTLS用語集

こちらのツイートから。

Today from the Let's Encrypt Glossary: OCSP Stapling https://t.co/mfxG9p5d8L

— Let's Encrypt (@letsencrypt) 2023年8月2日

リンク先はこちら。

letsencrypt.org

最終更新は2018年とやや古めだが、ACMEも載ってる。パッと意味を思い出すのに便利かも。

▼最近のQUIC利用状況

こちらのツイートから。

> パブリッククラウドにおけるQUIC現状確認2023年8月編https://t.co/SsaejbvxQ8

— ゆき (@flano_yuki) 2023年8月3日

リンク先はこちら。

slide.rabbit-shocker.org

youtubeとかgoogle fontのサイトとかはもうQUICらしい。

AWSでのCloud FrontとかALB/NLBの組み合わせ方が色々紹介されている。

▼Let's Encryptの功績

こちらのツイートから。

無料SSL/TLS証明書及びクライアントのCertbotが10周年に。有効な証明書は2.5億枚以上。10年前には23%だった、ページでのHTTPS使用率は78%になった（Firefox統計）。 https://t.co/ZHFdDoG6IR

— kokumօtօ (@__kokumoto) 2023年8月3日

リンク先はこちら。

www.eff.org

Firefoxのデータによると、2013年にブラウザの通信のうち27%だったHTTPS通信は、今では78%に達しているとのこと。100%を目指すのはOSCPとかCRLがある限り無理じゃ無いかと思ってるけどどうなんだろう。え、誰も使ってないって？

▼Zig 0.11.0のTLS1.3クライアント

こちらのツイートから。

tls13-zig の実装が役に立って嬉しい！ https://t.co/y6VM82yVe9

— Naoki MATSUMOTO (@PiBVT) 2023年8月4日

リンク先はこちら。

ziglang.org

時雨堂さんのインターンか何かで実装されたTLS1.3クライアントを参考に実装されたやつがリリースされたとのこと。そのおかげで、HTTPクライアントも同時リリースされたらしい。すごい。

▼CAインシデントレポートの改善提案

こちらのツイートから。

Here’s a really good post by Aaron Gable on WebPKI CA incident reports. https://t.co/7zGt9xrW24

— Ryan Hurst (@rmhrisk) 2023年8月4日

リンク先はこちら。

groups.google.com

CCADBのひとの呼びかけに対して、Let's EncryptのAaron Gable氏がコメント。GoogleのSRE本第二弾サイトリライアビリティワークブックや第三弾セキュアで信頼性のあるシステム構築のポストモーテムを参考に「教訓（うまくいったこと、うまくいかなかったこと、幸運だったこと）」の追加や、インシデントタイムラインのポイントなどが提案されている。
一般的な障害レポートとしてもアリな気がする。自分、できてるかなあ...。

[暗認本：16 ディスクの暗号化]

引き続き、ニュース以外のメインコンテンツとして『暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』を読んでいく。
今週はChapter 3 共通鍵暗号から、セクション16をざっとまとめた。

• TPM: Trusted Platform Module
  • PCやスマホのセキュリティ専用チップ
  • OS起動時にシステム改ざん検証可能
  • チップを取り出して解析しようとすると保存データ消去
  • TCG(Trusted Computing Group)が仕様策定
  • 秘密鍵のバックアップはできるが管理がポイント
• ディスクの構造
  • OSはブロック単位で読み書き
  • 512, 1024, 4096バイト
• XTS-AESの概要
  • 2004年のXEX(Xor Encrypt Xor)を元にしたXTS(XEX Tweekable block cipher with ciphertext Stealing)
  • WindowsのBitLocker、macOSのFileValue2、Linuxのdm-cryptなどで利用
  • 秘密鍵を2個利用
  • ディスク暗号化ではデータユニットのサイズが16の倍数
  • データユニットの番号をtweak(T)としで暗号化
    • tweakは同じ値の再利用可能
• XTS-AESの暗号化
  • 入力データをn個のブロックに分割
  • Si = Enc(K1, T) (x) α^i
    • 拡大体とかの話はセクション19で。
  • Ci = Enc(K2, Si (+) mi) (+) Si
• XTS-AESの安全性
  • データユニットが同じ場所にあるとTの値が同じ
  • 平文が同じなら暗号文が同じになる
  • 従来の安全性の観点からは評価しづらい
  • NISTやCRYPTRECの評価でも問題なし：元の平文を解読するのは容易ではない
• 自己暗号化ドライブ（SED: Self Enryptiing Drives）
  • ハードウェアで暗号化・復号するものも
  • ソフトウェアによるディスク暗号化より扱い安く、CPUリソース消費しない
  • パソコンのスリープ中などの秘密鍵攻撃可能性あり

[まとめ]

RFCとか、各社のアナウンスがあってから、最終的にそれがリリースされるまではやはりタイムラグがあるなあ、と再認識。

※以降に文章はありません。投銭スタイルです。

*1:TLSらじおは社内勉強会です。このブログを読み上げつつ弊社サービスの実情を語ったりします。

この続きはcodocで購入