Support externally supplied rotating TLS ticket keys for cross-node session resumption
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
調査の方向性
Start in src/tls.rs at the ticketer setup identified in the issue, then read rustls's ProducesTickets interface and the TLS-config caching path. The scope requires a rotating key ring, policy isolation, updates to cached and suspended routes, and cross-process TLS 1.2/1.3 validation. Done means the acceptance cases pass, including key rotation overlap and rejection across incompatible scopes and policies.
索引モデルが issue の本文から書いたものです。
説明
Problem
A client that obtains a TLS session ticket from cluster node A should be able to resume on node B serving the same TLS identity and policy. Today Symphony creates an independently randomized rustls::crypto::ring::Ticketer for each ServerConfig. Reusing the proxy's TlsConfigCache preserves tickets locally but does not synchronize keys across nodes or processes.
Follow-up to PR #57, requested in its review discussion. The current ticketer setup is in src/tls.rs.
Scope
Add an embedding and standalone-server configuration interface for an externally supplied, rotating ticket-key ring. The cluster management layer supplies keys; Symphony handles ticket encryption/decryption through rustls's ProducesTickets interface.
- Allow separate key rings or key scopes for different clusters sharing a proxy. Include the scope in TLS-config caching so otherwise identical cert/policy inputs cannot accidentally share a ticket provider across clusters.
- Scope tickets to compatible server identity, client CA and client-cert requirement, and ALPN policy. Use domain-separated derived keys or authenticated context binding. Preserve isolation when policy changes; rustls does not enforce equivalent configuration when sharing ticketers.
- Support an active encryption key and bounded previous decryption keys, with explicit key IDs and expiry. Key updates must reach existing cached configs and both static and resolved/suspended routes without requiring a listener restart.
- Use reviewed authenticated encryption and nonce generation safe across independent nodes sharing keys. Keep key material out of logs, debug output and metrics, and erase retired material. Define how missing/invalid configuration and expired keys fall back to full handshakes while preserving route isolation.
- Preserve the existing local-key behavior for deployments that do not configure shared keys. Document that identical certificates alone do not enable cross-node resumption.
Acceptance
- With separate proxy instances/processes using the same ring and compatible TLS configuration, obtain a ticket on A and resume on B under TLS 1.2 and TLS 1.3; confirm that resumption actually occurred.
- Exercise table routes and resolved/suspended routes, including updates to an already cached config.
- Roll out a next key before activation; show that tickets minted before and after activation resume during the overlap, and that expired/removed keys cause a full handshake.
- Verify rejection across different cluster scopes, server identities and incompatible mTLS/ALPN policies, including no-client-auth to required-client-auth transitions.
- Validate malformed/unknown keys and failed updates without breaking unrelated routes or exposing secrets.
TLS 1.2 session-ID resumption remains a separate state-storage concern; this issue covers ticket-based resumption and does not require a shared session database. Shared tickets do not imply enabling TLS early data.
Related: #58 tracks local cache loss on listener recreation; externally supplied keys should also survive proxy recreation while they remain valid.
Platform integration: Central Manager key custody/rotation: https://github.com/HarperFast/central-manager/issues/939; Host Manager route configuration/handoff: https://github.com/HarperFast/host-manager/issues/251.
- 主要言語
- Rust
- スター
- 1
- フォーク
- 0
- 平均マージ
- 19時間 12分
- マージ済み PR（30日）
- 13
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
HarperFast/symphony のほかの issue
-
Don't route to a restarted upstream until it serves, not just accepts対応中かも @kriszyp が 5 日前に担当しました。 オープン
HarperFast/symphony#84 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
Forward to a peer when the local upstream connect fails on a TLS-terminating failover route対応中かも @kriszyp が 5 日前に担当しました。 オープン
HarperFast/symphony#83 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
HarperFast/symphony#80 ·
メンテナーはふだん 1 日以内に返信
-
Forward a connection to a peer when its local upstream connect fails対応中かも @kriszyp が 5 日前に担当しました。 オープン
HarperFast/symphony#79 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
HarperFast/symphony#77 ·
メンテナーはふだん 1 日以内に返信
HarperFast/symphony の issue をすべて見る
似ている issue
-
area: cli kind:docs priority: P3
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
swc-project/swc-ai-issues#164 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
pop-os/cosmic-player#367 ·
-
good first issue help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
servo/rust-smallvec#873 ·