ToppyMicroServices

RFC 8446 Quiz

TLS 1.3のセキュリティ特性

🇺🇸 🇯🇵
0 / 0

References (URLs)

狙い: TLS 1.3が保証することと、保証しないことを切り分ける。

Q1: TLS 1.3の基礎設計目標として代表的な性質はどれ

Multiple Choice
**Explanation:** **Terms:** forward secrecy, ephemeral key exchange. 後から長期鍵が漏れても, 過去通信が復号されにくい性質. **Correct (C):** TLS 1.3はephemeral (EC)DHEやPSK系の設計で強い性質を狙う. **Options:** - A (incorrect): static RSA key exchangeはTLS 1.3で廃止. - B (incorrect): TLSの目的に反する. - C (correct): forward secrecyは中核. **Related:** 盗聴保存されたトラフィックへの後追い復号を難しくする.

Q2: 0-RTT early dataの主なリスクはどれ

Multiple Choice
**Explanation:** **Terms:** 0-RTT, early data, replay. handshake完了前にdataを送れるが, threat modelが変わる. **Correct (A):** early dataは状況によってreplayされ得るため, アプリ側で対処が必要. **Options:** - A (correct): replayが中核リスク. - B (incorrect): 0-RTTとは無関係. - C (incorrect): 逆. replay観点で弱くなる. **Related:** 0-RTTはidempotent操作などreplay-safeな用途に限定するのが一般的.

Q3: TLS 1.3のkey scheduleは一般に何に基づく

Multiple Choice
**Explanation:** **Terms:** key schedule, HKDF. handshake進行に応じて複数secretを派生させる設計. **Correct (B):** TLS 1.3はHKDFで段階ごとのsecretを導出し, 方向別のtraffic keyを持つ. **Options:** - A (incorrect): Base64はエンコードでKDFではない. - B (correct): HKDFがKDF. - C (incorrect): secretは段階で更新され, 方向別に分かれる. **Related:** handshake secretとapplication secretを分離すると, 漏えい時の影響範囲を抑えられる.

Q4: ServerHello以降, 多くのhandshake messageはどう扱われる

Multiple Choice
TLS 1.3 では, ServerHello までは初期handshakeとして見えていますが, そこで次段のsecretが決まると, 以降の多くのhandshake messageは保護されます.
ClientHello 初期の平文 交渉 ServerHello key share確定 secret導出 Handshake traffic key有効 以降を保護
**Explanation:** **Terms:** handshake traffic keys, encryption. TLS 1.3は以前より多くのhandshakeを暗号化する. **Correct (C):** secretが確立した後のhandshake messageは保護される. **Options:** - A (incorrect): TLS 1.3は平文露出を減らす. - B (incorrect): 圧縮が主役ではない. - C (correct): handshake messageは暗号化される. **Related:** handshake暗号化はprivacy改善とossification抑制に効く.

Q5: TLSがin transit dataに提供する基本保護はどれ

Multiple Choice
**Explanation:** **Terms:** confidentiality, integrity, replay. TLSは盗聴と改ざんを防ぐ. **Correct (A):** encryptionと認証で, 秘密性と完全性を提供. **Options:** - A (correct): 基本保護. - B (incorrect): 認可はアプリ側. - C (incorrect): early dataにはreplayの注意があり, アプリ側の対策が必要. **Related:** server認証はcertificateで行われることが多いが, trust判断はポリシー次第.

Q6: TLS 1.3でforward secrecyを得るためのephemeral key exchangeを1つ挙げよ

Short Text
**Explanation:** **Terms:** DHE, ECDHE, forward secrecy. Diffie-Hellman系のephemeral key exchange. **Correct:** DHEまたはECDHE. **Why others are wrong:** static RSA key exchangeはTLS 1.3で廃止. PSKは再開に使えるが, forward secrecyは追加要素に依存する. **Related:** key exchangeの選択は性能と暗号俊敏性に影響する.