RFC 7301 Quiz

**Explanation:** **問題を出した背景:** ALPN は HTTP/2 のための機能, という覚え方だけだと, 設計の本質を見失いやすいです. **用語:** **ALPN** は **Application-Layer Protocol Negotiation** です. TLS handshake の中で, 接続後に話す application protocol を決めます. **実務での機会:** 443 番 port で HTTP/1.1, HTTP/2, あるいは他の protocol を併用する server や proxy の review で頻出です. **選択肢:** - A (incorrect): certificate の暗号化方式を別にする話ではありません. - B (correct): これが ALPN の中心的な役割です. - C (incorrect): DNS-based discovery の置き換えではありません. **関連:** RFC 7301 は HTTP/2 を後押しした文脈がありますが, 交渉対象は HTTP 系に限りません.

**Explanation:** **問題を出した背景:** 交渉の責務分担を誤ると, client と server のどちらが protocol を決めるのかが曖昧になります. **用語:** **ClientHello** で client は自分の候補を列挙します. 最終的にどれを使うかを選ぶのは server 側です. **実務での機会:** 「client は h2 を出しているのに, なぜ HTTP/1.1 になったのか」を調べるときに, まずここを押さえます. **選択肢:** - A (correct): 候補リストを出すのが client の役目です. - B (incorrect): 1 個を強制する仕組みではありません. - C (incorrect): certificate chain を ALPN 候補として送るわけではありません. **関連:** protocol 選択は client の希望と server の都合の両方を踏まえて決まります.

**Explanation:** **問題を出した背景:** ALPN と SNI は一緒に語られやすいので, hostname routing と protocol negotiation を混同しがちです. **用語:** **SNI** は server name を伝えます. **ALPN** は application protocol を交渉します. 問題の層が違います. **実務での機会:** ingress, TLS terminator, certificate 事故の切り分けで, 「名前の問題」なのか「話す protocol の問題」なのかを分けて考えるのに重要です. **選択肢:** - A (incorrect): 役割の割り当てが完全に違います. - B (incorrect): 別物です. - C (correct): これが正しい整理です. **関連:** 実運用では SNI, ALPN, certificate selection, backend routing が組み合わさるので, それぞれの責務を分けて把握する必要があります.

**Explanation:** **問題を出した背景:** handshake 自体は成立しそうに見えるため, 「どこで protocol mismatch を止めるべきか」が曖昧になりやすいです. **用語:** **no_application_protocol** は, 共通の application protocol が無いときの alert です. **実務での機会:** h2 だけを想定した client と, HTTP/1.1 しか出せない origin や proxy の間で failure を読むときに役立ちます. **選択肢:** - A (incorrect): client が提示していない protocol を使うのは交渉として不正です. - B (correct): これが RFC 上の正しい failure です. - C (incorrect): plaintext への自動 downgrade は ALPN の fallback ではありません. **関連:** 正しく失敗させることは, 曖昧な成功よりずっと debug しやすく安全です.

**Explanation:** **問題を出した背景:** ALPN を単なる互換性の仕組みとだけ見ると, deployment 上の価値を見落とします. **用語:** **certificate selection** や **routing** は, negotiate された protocol に応じて server 側の挙動を変える設計です. **実務での機会:** multi-tenant ingress, TLS offload, protocol ごとに backend を分ける構成で意味を持ちます. **選択肢:** - A (correct): RFC の design discussion に沿った理解です. - B (incorrect): client が certificate を差し替える機構ではありません. - C (incorrect): certificate validation は依然として必要です. **関連:** hostname, protocol, certificate, backend の選択は別軸ですが, 現場では同じ handshake の中で絡み合います.

**Explanation:** **問題を出した背景:** ALPN を「ただの negotiation field」と思っていると, metadata leakage の論点を見逃します. **用語:** **externally visible marker** とは, application data 前の段階で on-path entity が connection の性質を推測できる手掛かりです. **実務での機会:** protocol 名そのものが profiling や policy decision に使われ得る環境では, ここを意識しないと設計が甘くなります. **選択肢:** - A (correct): RFC は古い TLS version を含め, identifier の可視性に注意を促しています. - B (incorrect): ALPN は protocol 秘匿の仕組みではありません. - C (correct): これが設計上の見方のひとつです. - D (incorrect): むしろ leakage に注意しろと書いています. **関連:** protocol 名自体が sensitive なら, 「ALPN で見える前提でよいか」を別途検討する必要があります.

**Explanation:** **問題を出した背景:** ALPN を単なる hint と見なすと, 交渉後の application behavior を緩く扱ってしまいます. **用語:** **definitive for the connection** は, その TLS connection 上で何を話すかを決める binding な結果だという意味です. **実務での機会:** front proxy と backend の protocol mismatch や, observability 上は h2 なのに実際は HTTP/1.1 相当で応答している, という事故を防ぐ観点で重要です. **選択肢:** - A (incorrect): それでは negotiation の意味が失われます. - B (incorrect): 最初の response までの一時的設定ではありません. - C (correct): これが RFC の意図するところです. **関連:** protocol negotiation が役立つのは, 双方が「この接続では何を話すのか」を曖昧にしないからです.

**Explanation:** **問題を出した背景:** 「resume だから前回の条件がそのまま残る」と思い込むと, connection property と session property を混同します. **用語:** ALPN は **session property** ではなく **connection property** として扱われます. つまり, 今回の handshake で決まるということです. **実務での機会:** client 側の候補が変わった, server 側の設定が変わった, といった再接続シナリオで重要です. **選択肢:** - A (correct): 新しい handshake の ALPN を見ます. - B (incorrect): 前回の値に固定されるわけではありません. - C (incorrect): 平文 side negotiation に戻るわけではありません. **関連:** TLS 周りの debugging では, 「session に紐づく情報か, 現 connection に紐づく情報か」を分ける癖が役立ちます.

**Explanation:** **問題を出した背景:** 現場では「TLS は通ったのに期待 protocol じゃない」という事故がよくあり, そこを SNI や証明書の問題と混同しがちです. **用語:** ALPN では client は候補を出し, server がその中から選びます. 成功したことと, 一番新しい protocol が選ばれたことは同じではありません. **実務での機会:** load balancer, CDN, origin のどこかで `h2` が無効になっていると, こうした見え方になります. **選択肢:** - A (incorrect): SNI は protocol を強制しません. - B (correct): これが一番現実的です. - C (incorrect): 最新 protocol を必ず選ぶ義務はありません. **関連:** debug のときは, client が何を offer したか, server が何を support しているか, 実際に何を select したかを分けて見ると早いです.

**Explanation:** **問題を出した背景:** RFC 7301 の学習ゴールは extension 番号を覚えることではなく, deployment failure を横断的に読めるようになることです. **用語:** **ALPN**, **SNI**, **certificate selection**, **routing** は別々の責務を持ちますが, 現場では同じ接続確立の流れの中で絡みます. **実務での機会:** ingress review, TLS incident, proxy config review で, どこに fault があるかを狭める comment としてそのまま使えます. **選択肢:** - A (correct): 最も operational に強い見方です. - B (incorrect): SNI は protocol negotiation の代わりになりません. - C (incorrect): TLS 成功だけでは, 想定通りの application protocol になっている保証にはなりません. **関連:** ALPN を本当に理解したと言えるのは, protocol negotiation を単体ではなく deployment 全体のつながりで説明できるときです.