ToppyMicroServices

RFC 2818 Quiz

HTTP over TLS (HTTPS)

🇺🇸 🇯🇵
0 / 0

References (URLs)

範囲: RFC 2818はInformational RFCであり, 現在はobsoleteです. RFC Editorは後継としてRFC 9110を示しています. RFC 2818を参照する問題は同文書が当時定めた規則を問うものであり, certificate照合の詳細を現在の一般的な指針として提示するものではありません.

Q1: schemeがhttpsのURLが意味することとして最も近いのはどれ

Multiple Choice
**Explanation:** **HTTPS** は **HTTP over TLS** です. つまり application protocol は HTTP のままで, transport の下に TLS が入ります. その結果, confidentiality, integrity, server authentication を期待できる, という理解が土台になります. `https` はHTTPをTLS上で運ぶことを示し,clientはcertificate検証と参照identityの照合を通じて接続先serverを確認します. HTTPS を使っていても, cert validation を無効化すると server authentication は崩れます. 「TLS を張った」だけで安心しないことが重要です. A: 同じ host が `http` と `https` の両方を提供することは普通です. `https` scheme は `http` 提供の禁止までは意味しません. B: scheme の意味と TLS の役割を正しく言い表しています. C: Base64 は単なる encoding です. HTTPS の本質である encryption や certificate validation とは無関係です.

Q2: https URLのdefault portはどれ

Multiple Choice
**Explanation:** **default port** は URL に port が明示されていないときに scheme から補われる既定値です. `https://example.com` は `https://example.com:443` と同じ接続先を指す想定で扱われます. `https` の既定 port は **443** です. URL に port が書かれていなければ, client はこの値を前提に接続先を解釈します. port を明示しない URL でも, origin 比較では既定 port が効きます. `https://example.com` と `https://example.com:443` を同じ origin とみなす理由もここにあります. A: `https` の既定値です. B: **80** は `http` の既定 port です. ここを混同すると scheme downgrade の説明まで曖昧になります. C: **22** は SSH でよく使われる port であり, HTTPS の既定値ではありません.

Q3: backendの境界で正当化できる結論はどれか?

Multi-Select

A2A clientは, URIと一致するcertificateを持つgatewayへHTTPS接続します. gatewayはTLSを終端し, 保護されていない内部接続でHTTP requestをbackendへ転送します. requestにはaccess tokenも含まれます.

**Explanation:** RFC 2818 Sections 2.1と3.1は, 1つのTLS connection内でHTTP dataを運び, そのconnectionのserverを識別する手順を扱います. TLS終端より先へchannelを延長せず, access tokenによるauthorizationも定義しません. A: 選択. この構成ではauthenticated channelはgatewayで終わります. B: 非選択. 転送requestはclient-to-gateway TLS peerのcryptographic evidenceではありません. C: 選択. HTTPS server authenticationはtoken validityやbackend resourceへの権限を決めません. D: 非選択. 別の保護されていないhopはTLSのconfidentialityやintegrityを引き継ぎません. E: 選択. これはRFC 2818が課すdeployment要件ではなく, 最初のhopを越える保証を宣言する前にarchitectureとして定義すべき境界です.

Q4: user inputから送信先URLを作り, access tokenを付けることがある. HTTP downgradeを防ぐvalidation policyはどれ

Multiple Choice
**Explanation:** RFC 2818 Section 2.3はHTTP over TLSのURI schemeを`https`と定め,`http`と区別します.scheme validationはsensitive requestを送る前に行う必要があり,`http` URLならtokenを含む最初のrequestがTLS protectionの外へ出ます. A: redirectは最初のinsecure requestを送った後にしか届かず, そのrequestを保護できません. B: host validationは送信先を絞りますが, 許可hostへのplaintext transportを防ぎません. C: tokenを付ける前に送信先とschemeを検証すれば, scenarioのdowngrade pathを閉じられます.

Q5: RFC 2818に基づくendpoint identificationのreviewとして正しいのはどれか?

Multiple Choice

clientはhttps://agent.example/cardをdereferenceします. DNSは203.0.113.10を返し, certificateにはagent.exampleというdNSNameがあります. clientは特定のcertificateを期待する外部情報を持ちません. reviewerはcertificateをresolved IPとのみ照合する案を示しました.

**Explanation:** RFC 2818 Section 3.1はURI内のhostnameから始め, それをcertificateのserver identityと照合します. URI自体がIP addressを含む場合には別のIP literal ruleを使います. A: DNSはrouting addressを与えますが, このURIのreference hostnameを置き換えません. B: 正解. certificateのdNSNameをagent.exampleと評価します. C: endpoint identificationを伴わないencryptionでは, 間違ったendpointやattackerのendpointとの接続を保護してしまいます. D: issuerへのtrustはpath validationの一部ですが, そのissuerの全certificateがこのserviceを表すことにはなりません.

Q6: RFC 2818のIP-literal ruleから導かれる結果はどれか?

Multiple Choice

clientはhttps://192.0.2.10/へ接続します. certificateには文字列192.0.2.10を含むdNSNameがありますが, iPAddress subjectAltNameはありません.

**Explanation:** RFC 2818 Section 3.1はURIをIP addressで指定した場合, `iPAddress` subjectAltNameが存在し, URIのaddressとexact matchすることを求めます. 文字列が同じ`dNSName`ではこのruleを満たしません. A: ruleは表示文字だけでなくname formも区別します. B: 同文書はhostnameの`dNSName`とIP literalのexact-match ruleを分けています. C: RFC 2818当時のendpoint-identification手順ではこれが正解です. D: portはURI hostを表すcertificate name formを変更しません.

Q7: RFC 2818が記したruleでは, このwildcard identityはmatchするか?

Multiple Choice

URI hostはapi.prod.agents.exampleです. certificateのdNSNameは*.agents.exampleです. 現在のcertificate service指針ではなく, RFC 2818本文のmatching ruleだけを評価します.

**Explanation:** RFC 2818 Section 3.1は*が1つのdomain-name componentまたはcomponent fragmentとmatchするとし, *.a.comはfoo.a.comとはmatchするがbar.foo.a.comとはmatchしない例を示します. A: 1つのwildcardに複数componentを消費させています. B: RFC 2818本文のruleでは正解です. *.agents.exampleが覆えるのはagents.exampleの直前の1 labelです. C: certificate pathへのtrustとreference identityのmatchは別の検査です. D: 同RFCはwildcard matchingを明記しています. 不成立の理由は全面禁止ではなくdepthです.

Q8: RFC 2818では, このconnection closeをどう分類するか?

Multiple Choice

HTTP responseにContent-Lengthはなく, connection closeだけがbody終端を示します. clientが有効なTLS closure alertを受け取る前にTCP connectionが終了しました.

**Explanation:** RFC 2818 Sections 2.2と2.2.1は, 有効なTLS closure alertを伴わないtransport closeをpremature closeと呼びます. Content-Lengthがない場合, clientは意図した終端とattackerによるtruncationを区別できず, errorとして扱い, そのsessionを再利用できません. A: unauthenticated closeは, 同sectionが警告する曖昧なsignalそのものです. B: 正解. HTTP truncationのriskとTLS sessionの再利用禁止を両方維持します. C: server authenticationは, 長さが未定義のresponseが意図した終端まで届いたことを証明しません. D: prematurely closed sessionのresumeは明示されたno-reuse ruleに反し, 過去のbody boundaryも証明できません.

Q9: 宣言されたresponse lengthをすべて受信した場合, どの結論が導けるか?

Multi-Select

responseには有効なContent-Lengthがあり, clientは指定された数のbody byteをすべて受信しました. その後, 有効なTLS closure alertなしにconnectionが終了しました.

**Explanation:** RFC 2818 Sections 2.2と2.2.1は, HTTP messageがcompleteか, 受信済みprotected dataを信頼できるか, TLS sessionを再利用できるかを別々に扱います. A: 選択. Section 2.2.1は宣言量のdataを受け取ったrequestについてこの例外を示します. B: 選択. applicationがcomplete messageを識別できても, Section 2.2はpremature close後のsession再利用を禁止します. C: 選択. 同文書は問題をsubsequent dataのtruncation可能性とし, 受信済みdataの自動的なcompromiseとはしません. D: 非選択. closure alertの欠如がpremature closeとauthenticated closureを分けます. E: 非選択. HTTP completenessはTLS sessionの再利用禁止を解除しません.

Q10: HTTPS validation成功後も不足している保証はどれか?

Multiple Choice

agentはunsigned discovery messageからhttps://attacker.example/cardを受け取ります. TLSでURLを取得し, certificateはattacker.exampleを正しく識別します. 取得したCardは保護対象A2A serviceへのauthorityを主張しています.

**Explanation:** RFC 2818 Section 3.1は, endpoint checkがcompromised URI sourceからのattackを防がないと警告します. この場合TLSが証明するのはattackerが選んだURIのendpointへ到達したことであり, 別serviceに関するそのendpointの主張をauthorizeしません. A: 選択済みendpointのauthenticationと, そのendpointを選んだ者のauthorizationを混同しています. B: token audienceとCard authorityは別のclaimであり, matching HTTPS certificateだけでは成立しません. C: 正解. applicationには, 誰が保護対象serviceのmetadataを導入または署名できるかというtrust ruleが必要です. D: port選択では欠けているprovenanceとauthority bindingを直せません.