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

[RFC 9345 Delegated Credentials]

こちらのツイートから。

RFC 9345
Delegated Credentials for TLS and DTLShttps://t.co/pGrjZC1wui
— ゆき (@flano_yuki) 2023年7月14日

リンク先はこちら。

Googleが進めている短命証明書だが、そうした証明書の場合更新頻度が増えるため、更新タイミングでの認証局障害による影響を受ける確率が高まる。
そのような問題を回避するために、元々の証明書の有効期間内かつ同一ドメインについて、まるで中間認証局のように「Delegated Credentials」を発行し、新しい秘密鍵での通信が可能になるとのこと。

TLS拡張としてdelegated_credential(34)をClientHelloメッセージに含め、サーバはCertificateメッセージの拡張としてDelegatedCredentialを埋め込んで送信する。

// Certificateハンドシェイクメッセージ
struct {
  opaque certificate_request_context<0..2^8-1>;
  CertificateEntry certificate_list<0..2^24-1>;
} Certificate;

struct {
  select (certificate_type) {
    case RawPublicKey:
    /* From RFC 7250 ASN.1_subjectPublicKeyInfo */
      opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
    case X509:
      opaque cert_data<1..2^24-1>;
  };
  Extension extensions<0..2^16-1>;
} CertificateEntry;

// CertificateEntryのExtensionとして送信
struct {
  Credential cred;
  SignatureScheme algorithm;
  opaque signature<1..2^16-1>;
} DelegatedCredential;

struct {
  uint32 valid_time;
  SignatureScheme dc_cert_verify_algorithm;
  opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
} Credential;

Wikipediaの記載によると、仕様の提案元のCloudFlareとFacebookが既にサポートしているらしい。ブラウザ側ではFirefox（のNightlyまたはBeta）がサポートしているとのこと。

en.wikipedia.org

[オンプレ製品の証明書]

こちらのツイートから。

稼働から2年でふだんの運用上気づかないSSL証明書期限切れで爆発する💣 vCenter Server (Applicance)

昨日、見事に爆発💣💣💣。で、朝来て、なにこれ状態。https://t.co/RDnEi11gqq https://t.co/mU7CKdLsPJ
— ふじた_🐱♨️💻雑用係 (@nfujita55a) 2023年7月10日

リンク先はこちら。

t-dilemma.info

ソフトウェアに同梱されてる証明書の類はこの手の問題がある...。ルートユーザーのパスワード期限とかもそうだけど。

ところで、サーバ証明書の有効期限は2018年に2年間、2020年以降は13ヶ月となったけど、vSphereはまだ2年のままなのだろうか。

ssl.sakura.ad.jp

加えて、Googleがサーバ証明書の有効期限を90日にしようとしているけれど、これが実現したら、この手の問題がさらに加速しそう...。

kdnakt.hatenablog.com

製品インストール時に別途ルート証明書を各端末にインストールするようになれば、Chromeの場合はCA/B Forumの398日の有効期限の制限を受けないから、そういう方向になるのだろうか。とはいえ10年以上の期限を指定するのは問題がありそうだから、結局問題発生を先送りするだけか...。

kdnakt.hatenablog.com

[その他のニュース]

▼Let's Encryptのクロス署名廃止

こちらの記事から。

letsencrypt.org

gigazine.net

2024年9月末にクロス署名に利用されている証明書の有効期限が切れること、Let's Encryptのルート証明書であるISRG Root X1を搭載したAndroid 7.1以降が93%を超えたこと、などを理由に、クロス署名を廃止するらしい。

Android、昔使ってた時はバージョン4とかだったのにいつの間にか随分バージョン番号が進んでいる...。

クロス署名は他にもいろんなところで使われている。

まぁもういいでしょう。ちなみにAWSのCertificate Manager発行の無料SSL証明書もクロス署名か何かが理由でサーバ側から4枚も証明書が送られてくるので通信量が大きかったはずです。 / “Let’s Encryptがクロス署名を廃止すると発表、証明書のデータ量が40％削減される一方で…” https://t.co/L0Ubs9Z6rK
— matsuu (@matsuu) 2023年7月16日

AWSのACMの場合はStarfield G2がそれに当たる。ACMのルートがiOSのトラストストアに入ったのはiOS 11以降らしい。

docs.aws.amazon.com

▼パケットキャプチャで理解する TLS1.3

こちらのツイートから。

Zenn で「パケットキャプチャで理解する TLS1.3」という本を書きましたhttps://t.co/53Ae7zAMW9
— arailly (@arailly_) 2023年7月4日

リンク先はこちら。

zenn.dev

無料で読めるらしい。ありがたや。

OpenSSLの代わりにCloudFlareのツールcfsslを利用して認証局を構築・証明書を発行し、Wiresharkでパケットを復号できるようにして通信を理解していく流れ。GoのHTTPサーバがTLS1.3で必須ではないChangeCipherSpecを送っていたりして面白い。

github.com

▼HTTP/3と日本

こちらのツイートから。

* HTTP/3は、日本の光回線だと、パフォーマンスの利点はない。（低レイテンシ・帯域幅が大きい）
* HTTP/3は、日本のドコモなどの携帯回線のようなパケットロスが多発している回線だとHTTP/2と大差がない。HTTP/2は、1.1より遅いことが判明しているので、HTTP/1.1より遅い。…
— Yoichiro Takehora (竹洞陽一郎) | 株式会社Spelldata (@takehora) 2023年7月13日

リンク先はこちら。

arxiv.org

HTTP/3が標準化される少し前の2021年の論文。自サービスで利用しているロードバランサのHTTP対応バージョンをどうするべきか悩んでたけど、1.1のままでいいのかもしれない。

▼証明書のアジリティ

こちらのツイートから。

Certificate lifetimes have been reduced drastically over the years, from 60 months, to 39 months, 825 days, 398 day, and next, 90 days?..

Let's take a look at what our next step for certificates lifetimes might be!https://t.co/zWKo77bcEG
— Scott Helme (@Scott_Helme) 2023年7月14日

リンク先はこちら。

scotthelme.co.uk

Googleの進めている証明書の有効期限短縮について、認証局やCTログの視点からも分析している。Let's Encryptも発行数が増加したら耐えられるのだろうか...。

▼WebSocket ALBのBlue/Greenデプロイ

こちらのツイートから。

ウン十万接続のALB SSL証明書を平和に更新したい - Nature Engineering Blog https://t.co/mGWmZNb9Qt miteru
— V (@voluntas) 2023年7月16日

リンク先はこちら。

engineering.nature.global

ALB2台を使って綺麗にブルーグリーンを実現していてすごい。

▼安全なSSL/TLS証明書更新

こちらのツイートから。

弊社ブログです。わいわい / “安全にSSL/TLS証明書を更新するために” https://t.co/Et6g9rCeOY
— matsuu (@matsuu) 2023年7月16日

リンク先はこちら。

heartbeats.jp

証明書のチェックツールとしてcheck-tls-certコマンドが紹介されていた。

github.com

オンラインで利用できるDigiCertのチェッカーも良さそうだけど、SSL Server Test (Powered by Qualys SSL Labs)の方が機能が多いので、オンラインで使うならこっちかな。

[暗認本：13 ブロック暗号]

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

ブロック暗号
- ブロックごとに暗号化。あまりはパディングで処理。
- 暗号化モードによりブロックごとの暗号化方法が異なる
ブロック暗号の歴史
- 1970年代：DES（Data Encryption Standard）
  - 64ビットブロック、鍵長56ビット
- 1990年代：DESへの攻撃が発展、一日足らず
- 1997年：NISTがAES(Advanced Encryption Standard)公募
- 1998年：AES決定までのつなぎとして3DES利用開始
- 2001年：Rijndael暗号がAESとして選出
AESの概要
- 128ビットブロック、鍵長は128/192/256ビット
- 暗号化＝初期設定＋ラウンド関数の繰り返し＋最終ラウンド
- ラウンド関数：鍵長に応じて9/11/13回
- 鍵長128ビット＝全探索でO(2^128)のコスト
  - 2011年のO(2^126.1)のBiclique攻撃が2020年時点で最も高効率
AESの初期設定
- 128ビットのブロックを8ビットずつ16個に分割(x0-x15)
  - 左上から縦にx0, x1, x2...
- AddRoundKey処理：ラウンド鍵とブロックの排他的論理和
ラウンド関数
- SubBytes、ShiftRows、MixColumns、AddRoundKey
- SubBytes：256文字の換字表S-Boxで8ビットずつ置き換え
- ShiftRows：以下のようにずらす

x0  x4  x8 x12      x0  x4  x8 x12 
x1  x5  x9 x13  ->  x5  x9 x13  x1 
x2  x6 x10 x14     x10 x14  x2  x6
x3  x7 x11 x15     x15  x3  x7 x11

- MixColumns：縦の列ごとに決められた行列Aをかける
  - 拡大体については詳細はセクション19
  - 最終ラウンド関数ではMixColumns以外を実行
AES-NI：New Instructions
- IntelやAMDのCPUのAESを高速処理する専用命令
  - aeskeygenassist
  - aesimc
  - aesenc
  - aesenclast
  - aesdec
  - aesdeclast
- スマホでもARMで専用命令あり

[まとめ]

物理オレオレ証明書初めて見た...。

せっかくなのでこの写真pic.twitter.com/NsfrTqXBrY
「オレオレ証明書（物理）」としてフリー素材にします
常識の範囲内でお使いください… https://t.co/vKzZ9vIjz8
— 上原哲太郎/Tetsu. Uehara (@tetsutalow) 2023年7月13日

ランキング参加中

プログラミング

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

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

この続きはcodocで購入

kdnakt blog

hello there.

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

[RFC 9345 Delegated Credentials]

[オンプレ製品の証明書]

[その他のニュース]

▼Let's Encryptのクロス署名廃止

▼パケットキャプチャで理解する TLS1.3

▼HTTP/3と日本

▼証明書のアジリティ

▼WebSocket ALBのBlue/Greenデプロイ

▼安全なSSL/TLS証明書更新

[暗認本：13 ブロック暗号]

[まとめ]