ToppyMicroServices

RFC 6797 Quiz

HTTP Strict Transport Security

🇺🇸 🇯🇵
0 / 0

References (URLs)

範囲: RFC 6797は, hostがHSTS policyを伝え, conformingなuser agentがそれを学習・強制する方法を定義します. preload登録は別のuser-agent機能であり, HSTS/TLSの成功だけではapplication identity, authorization, delegationは成立しません.

Q1: user agentのHSTS stateを更新できるresponseはどれ?

Multiple Choice

gatewayがapi.exampleから3つのresponseを観測しました. 1つはplain HTTP, 1つはcertificate warningを伴うTLS, 1つはunderlying security errorのないTLSです. すべてにStrict-Transport-Security: max-age=86400があります.

**Explanation:** A: field syntaxが有効であることは必要ですが十分ではなく, insecure transportで受け取ったSTS fieldは無視します. B: RFC 6797 Section 8.1は, secure transportにunderlying errorまたはwarningがないことも要求します. C: errorのないsecure responseはtransportの前提を満たし, Known HSTS Host entryを作成または更新できます. D: Section 7.2はHSTS Hostがinsecure transport上のresponseにSTS fieldを含めてはならないとし, Section 8.1はuser agentにそのfieldを無視させます.

Q2: load前にこのURIをどう変換しなければならない?

Multiple Choice

user agentはservice.exampleをすでにHSTS Hostとして知っています. http://service.example:8080/tasksをloadするよう指示されました.

**Explanation:** A: Section 8.3は, matchingするHTTP URIをload前にuser agentが書き換えるよう要求しており, insecureなserver redirectを待ちません. B: schemeをhttpsへ変え, 80以外のexplicit portは保持します. C: 80なら443へ変換しますが, RFC 6797はすべてのexplicit portを443へ置換しません. D: HSTSはportをまたいで適用されます. そのportがTLSを提供しなければ書換え後のHTTPS requestは失敗し得ますが, port番号だけを理由に拒否する規則ではありません.

Q3: certificate validation失敗後, user agentはどうしなければならない?

Multiple Choice

agent.exampleはKnown HSTS Hostです. TLS確立時にhostname validationが失敗しましたが, userはwarningをclick-throughして続行したいと考えています.

**Explanation:** A: user recourseを認めると, HSTSが除こうとするman-in-the-middle判断を再び開きます. B: HTTPへのfallbackはKnown HSTS Host policyに反します. C: includeSubDomainsはhost coverageを変えますが, coverされたhostのsecure-transport error処理は変えません. D: RFC 6797 Section 8.4はunderlying secure-transport errorがあれば接続終了を要求します. Section 12.1は対応するno-user-recourse動作を説明します.

Q4: child hostは引き続きHSTSでcoverされる?

Multiple Choice

example.comにはincludeSubDomainsを伴う期限内のHSTS policyがあります. その後api.example.comが, errorのないTLS responseでStrict-Transport-Security: max-age=0を返しました.

**Explanation:** A: RFC 6797 Sections 5.3と8.1.1は発行hostごとにpolicyを保持し, childはparent entryを削除できません. B: zero lifetimeはchildが独立に保存したpolicyを削除しますが, parent coverageからの除外指定にはなりません. C: Sections 5.4と8.2のdomain matchingでは, includeSubDomainsがassertされた期限内のparentが引き続きmatchします. D: child fieldは処理され, child自身のentryは削除されます. coverageが続く理由は別のparent entryです.

Q5: bootstrap boundaryを正しく述べたreview結論はどれ?

Multiple Choice

新しいA2A dashboardはHTTPをHTTPSへredirectし, HTTPS responseでStrict-Transport-Security: max-age=31536000; includeSubDomains; preloadを返します. teamは, siteへ接触したことのないbrowserもRFC 6797だけで最初から保護されると主張しています.

**Explanation:** A: 後で受け取ったpolicyは, それ以前のinsecure requestを保護できません. B: Section 14.6はbootstrap MITM vulnerabilityを示し, Section 12.3はpre-loaded Known HSTS Host listをuser-agent機能として論じます. RFC 6797がSTS directiveとして定義するのはmax-ageとincludeSubDomainsだけです. C: browserの登録programが運用上このtokenを使うことはあっても, preloadはRFC 6797が定義するdirectiveではありません. D: errorのないsecure transportで受け取った有効なfieldはpolicyを自動的に確立でき, 手動承認は要件ではありません.

Q6: HSTS/TLSの強制成功からbackendは何を結論できる?

Multiple Choice

browserはKnown HSTS HostのA2A gatewayへerrorのないTLSで到達しました. gatewayはAgent Card, bearer grant, high-impact taskの要求をbackendへ転送します. 設計案は, browser接続の成功をcard, grant, sender runtime, task parameter, onward delegationのすべてがauthorizedである証拠として扱います.

**Explanation:** A: RFC 6797はuser-agentのtransport動作を制御します. Agent Card integrity, token validation, runtime attestation, task approval, delegation semanticsは定義しません. B: browserがHSTSで保護された接続からgatewayへ到達しても, cardやgrantが自動的にvalidにはなりません. C: RFC 6797 Sections 5.2, 8.3, 8.4はtransport policyの強制, URI書換え, secure-transport error処理を定義します. application判断は独立しており, A2A, signature, OAuth, sender-constraining, authorizationの該当規則により, gateway-to-backend trust boundaryを含む追加claimを確立する必要があります. D: RFC 6797はapplication-level credentialの転送を許可も禁止もせず, その判断は他protocolとsystemのtrust modelに属します.