kdnakt blog

hello there.

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

TLSらじお SSL/TLS

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

[IETF117: TLS WG]

こちらのツイートから。

アジェンダをみるとECH(Encrypted Client Hello)の話がメインだったっぽい。
こちらのツイートによると、Chromeの安定版で1%のユーザが利用中とのこと。多分スライドの7ページにある実験的リリースの話で、12月までに1%ということらしい。ユーザーの1%なのかコネクションの1%なのか、実験のやり方とか気になる。Firefoxでも同様に実験予定とのこと。

TLS 1.2 is Frozenのスライドはこちら。ドラフトはこっち。新しいアルゴリズムは無しなので、当然耐量子暗号(PQC)も無しですよ、と。

耐量子暗号の署名についてのスライドも。先週のブログで「どうやって減らしていく」のか気になっていたけど、署名サイズや検証時間などの観点で比較がされていた。証明書での利用だと公開鍵のサイズも重要になってくる...なるほど。DME-Sign、MAYO、UOV、SQISignあたりが筆頭候補っぽい。

Abridged Compression for WebPKI Certificatesというドラフトの話も(スライド)。Mozillaの人が書いてるっぽい。耐量子暗号証明書への移行をスムーズにするための圧縮の話で、CCADB(Common CA Database)を元にした共有辞書をベースにルート証明書や中間証明書を省略できるようにするとのこと。CCADB、失効情報のプリロードとかにも利用されているけど、こんな使い方が...。
ドラフトによると、CCADBには現在200のルート証明書と2000の中間証明書が含まれているとのこと。証明書の圧縮自体はRFC 8879で定義されているものを利用するっぽい。

datatracker.ietf.org

[IETF117: ACME WG]

こちらのツイートから。

MTGのアジェンダをみると、確かにACME(Automated Certificate Management Environment)についての単体のセッションがある。

datatracker.ietf.org

スライドによると、ARI(ACME Renewal Information)について、Fastlyの運営するCAであるCertainlyでもサポート準備中とのこと。
匿名通信のTorネットワーク用の.onionドメインでもACMEを利用できるように、というドラフトがあった(スライド)。Torの性質上、DNSを利用できないのでワイルドカード証明書の更新に問題があるらしい。

他にもいろんなインターネットドラフトが進行中。IP通話向けのACMEの仕様とかもあって追いきれない...。

[IETF117: PQUIP WG]

こちらのツイートから。

Post-Quantum Use In ProtocolsでPQUIPとのこと。
RFCやドラフトの整理リポジトリ、PQCハイブリッド向け用語集などに混じって、エンジニア向けPQC説明が。これは読んで勉強せねば...。

こんな発表もあったらしい(スライド)。Googleのデータセンター間の通信にPQCを利用しているとのこと。

[IETF117: Crypto Forum RG]

こちらのツイートから。

ドキュメントが大量...アクティブなドラフトだけで19本あるらしい。

datatracker.ietf.org

AEAD(認証付き暗号)の利用制限、暗号仕様のガイドライン、AEGIS暗号、などなど。
AEGISはスライドによると、C、Rust、Zig、GoだけでなくKotlinやJavaScriptの実装もあり、通常のAES-128-GCMより3倍くらいスループットが出ているとのこと。

[その他のニュース]

▼IETF117: 低遅延暗号Areion

こちらのツイートから。

AESをベースにしたやつらしい。OpenSSLにQUICの機能を追加したフォークquictlsにTLS_AREION256_OPP_SHA256という暗号スイートを追加したとのこと。OPP(Offset Public Permutation)は暗号利用モードでAEAD(認証付き暗号)の1種らしい。

▼BraveのCT対応

こちらのツイートから。

リンク先はこちら。

certificate.transparency.dev

Chrome、Safariに続いてBraveがCT(Certificate Transparency)に対応したらしい。あれ？と思ったけどFirefoxは実は対応してないとのこと。ちょっと意外。

▼CloudFrontの3072ビットRSA証明書サポート

こちらのツイートから。

リンク先はこちら。

aws.amazon.com

ECDSAが使えないクライアント向けってことですかね。他にも問題がありそうだから、早くクライアントをアップデートしたほうが良さそう...。と思ったけどCA側の問題もあるっぽい。なるほど。

▼Microsoftの証明書ミス

こちらのツイートから。

sharepoint.comにsharepoint.deの証明書をデプロイしちゃったみたい。そんなことあるんだ...。しばらくして直ったというかロールバックされた模様。

▼時雨堂のOSSスポンサー更新

こちらのツイートから。

ブログでこうしてOpenSSLやLet's Encryptをネタにできるのもこうした支援あってのこと。ありがたや🙏

▼AWSのパブリックIPv4アドレス有料化

こちらの記事から。

aws.amazon.com

2024年2月からだそうで。大した金額ではなさそうだけど、IPv6への移行とかを真面目に考える時が来たのかもしれない。プロフェッショナルIPv6第2版を読まねば...（無料版もある）

プロフェッショナルIPv6 第2版

プロフェッショナルIPv6 第2版

Amazon

▼IoTと暗号アルゴリズム

こちらのツイートから。

リンク先はこちら。

datatracker.ietf.org

GCMはこのあと暗認本のパートで出てくる暗号化モードのひとつで、いわゆる認証付き暗号というやつ。
AES128とAES256の違いは鍵の長さだけど、少し前に暗認本で読んだように、鍵の処理時間とかも微妙に長くなるし、128で十分安全だし、ということなのかな？IoTだと色々制約がありそうだけどよくわからない...。

[暗認本：15 暗号化モード]

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

  • ECB(Electronic CodeBook)モード
    • 平文をブロックに分割しそれぞれ暗号化
    • CodeBook=換字表
    • ECBは同じ平文が同じ暗号文になるので危険
  • CBC(Cipher Block Chaining)モード
    • 暗号文＝Enc(平文 (+) 1つ前の暗号文, 秘密鍵)
    • 先頭ブロックでは暗号文がないので、初期化ベクトル(Initialization Vector)を利用
    • 前の暗号文と排他的論理和をとるため、平文が同じでも暗号文が異なる
  • CTR(CounTeR)モード
    • 暗号文＝平文 (+) Enc(ナンス + カウンタ)
    • ブロック暗号で生成した擬似乱数をナンスとして利用するストリーム暗号
    • ナンスは平文のまま相手に渡す
  • CBCモードとCTRモードの比較
    • CBCでの暗号化には前のブロックの暗号文が必要
      • ＝並列処理できない
    • CTRでは独立して複数CPUで暗号化
  • CBCモードに対する攻撃
    • SSL/TLSで広く使われていた
    • 2011年以降、BEAST、CRIME、Lucky 13、POODLEなどの攻撃が発見

[まとめ]

IETF117の話題が多くて色々取りこぼしている気がする...。

ランキング参加中
プログラミング

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

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

この続きはcodocで購入