ToppyMicroServices

RFC 2818 Quiz

HTTP Over TLS (HTTPS)

πŸ‡ΊπŸ‡Έ πŸ‡―πŸ‡΅
0 / 0

References (URLs)

Scope: RFC 2818 is an Informational RFC that is now obsolete, with RFC 9110 listed as its successor. Questions that cite RFC 2818 ask what that historical document says; they do not present its certificate-matching details as current general guidance.

Q1: A URL with scheme https implies

Multiple Choice
**Explanation:** RFC 2818 defines HTTPS as HTTP carried over TLS. When the server hostname is known from the URI, the client generally checks it against the identity presented in the server certificate. A: The scheme describes this resource access; it does not permanently prohibit the same host from serving HTTP. B: It combines HTTP over TLS with the endpoint-identification expectations specified for HTTPS. C: Base64 is an encoding and provides neither TLS encryption nor server authentication.

Q2: The default port for https URLs is

Multiple Choice
**Explanation:** RFC 2818 records **443** as the default TCP port for HTTP over TLS. A URL can still contain another explicit port; default does not mean mandatory for every deployment. A: `443` is the registered default for an HTTPS URL with no explicit port. B: `80` is the conventional default for plain HTTP. C: `22` is commonly associated with SSH, not HTTPS.

Q3: Which conclusions are justified at the backend boundary?

Multi-Select

An A2A client opens HTTPS to a gateway, whose certificate identity matches the URI. The gateway terminates TLS and forwards the HTTP request to a backend over an unprotected internal connection. The request also carries an access token.

**Explanation:** RFC 2818 Sections 2.1 and 3.1 describe HTTP data inside a TLS connection and server identification for that connection. They do not extend the channel beyond the endpoint that terminates TLS or define access-token authorization. A: Selected. The authenticated channel ends at the gateway in this deployment. B: Not selected. A forwarded request is not cryptographic evidence of the client-to-gateway TLS peer. C: Selected. HTTPS server authentication does not decide whether the token is valid or whether its subject may access the backend resource. D: Not selected. A separate unprotected hop does not inherit TLS confidentiality or integrity. E: Selected as an architectural conclusion. This is not a deployment rule imposed by RFC 2818; it is what must be specified before claiming protection beyond the first hop.

Q4: Your app builds a destination URL from user input and may attach an access token. Which validation policy best prevents an HTTP downgrade?

Multiple Choice
**Explanation:** RFC 2818 Section 2.3 defines `https` as the URI scheme for HTTP over TLS and distinguishes it from `http`. Scheme validation must happen before a sensitive request is sent: an `http` URL would place the first request, including any attached token, outside TLS protection. A: A redirect occurs only after the initial insecure request has already left the client. B: Host validation limits destinations but does not prevent plaintext transport to an allowed host. C: Checking both destination and scheme before adding the token closes the downgrade path in the scenario.

Q5: Which endpoint-identification review is correct under RFC 2818?

Multiple Choice

A client dereferences https://agent.example/card. DNS returns 203.0.113.10, and the certificate contains a dNSName of agent.example. The client has no external information identifying one expected certificate. A reviewer proposes comparing the certificate only with the resolved IP address.

**Explanation:** RFC 2818 Section 3.1 starts from the hostname in the URI and requires the client to compare it with the server identity in the certificate. Its separate IP-literal rule applies when the URI itself contains an IP address. A: DNS supplies a routing address; it does not replace the reference hostname in this URI. B: Correct. The certificate's `dNSName` is evaluated against `agent.example`. C: Encryption without endpoint identification can protect a connection to the wrong or attacker-controlled endpoint. D: Trusting an issuer is part of path validation, but it does not establish that every certificate from that issuer represents this service.

Q6: What result follows from RFC 2818's IP-literal rule?

Multiple Choice

A client connects to https://192.0.2.10/. The certificate has a dNSName containing the text 192.0.2.10, but no iPAddress subjectAltName.

**Explanation:** RFC 2818 Section 3.1 says that when the URI is specified as an IP address, an `iPAddress` subjectAltName must be present and must exactly match the URI address. A textually similar `dNSName` does not satisfy that rule. A: Name form is part of the rule, not only the rendered characters. B: The document uses `dNSName` for a hostname and a distinct exact-match rule for an IP literal. C: Correct under RFC 2818's historical endpoint-identification procedure. D: The port does not change which certificate name form represents the URI host.

Q7: Does this wildcard identity match under RFC 2818's stated rule?

Multiple Choice

The URI host is api.prod.agents.example. A certificate contains the dNSName *.agents.example. Evaluate only the matching rule written in RFC 2818, not current certificate-service guidance.

**Explanation:** RFC 2818 Section 3.1 says that * matches a single domain-name component or component fragment. Its example says *.a.com matches foo.a.com, but not bar.foo.a.com. A: This incorrectly lets one wildcard consume multiple components. B: Correct for the rule in RFC 2818. *.agents.example can cover one label before agents.example, not two. C: Certificate-path trust and reference-identity matching are separate checks. D: RFC 2818 explicitly describes wildcard matching; the reason for rejection here is depth, not a categorical ban.

Q8: How should the client classify this connection close under RFC 2818?

Multiple Choice

An HTTP response has no Content-Length; connection close is therefore the only end-of-body signal. The TCP connection ends before the client receives a valid TLS closure alert.

**Explanation:** RFC 2818 Sections 2.2 and 2.2.1 call a transport close without a valid TLS closure alert a premature close. With no Content-Length, the client cannot distinguish an intended end from attacker-induced truncation, must treat the close as an error, and must not reuse that session. A: The unauthenticated close is exactly the ambiguous signal the section warns about. B: Correct. It preserves both the HTTP truncation warning and the TLS session-reuse prohibition. C: Server authentication does not prove that an unbounded response reached its intended end. D: Resuming the prematurely closed session violates the explicit no-reuse rule and cannot retroactively establish the body boundary.

Q9: Which conclusions follow when the declared response length was fully received?

Multi-Select

A response declares a valid Content-Length, and the client receives exactly that many body bytes. The connection then ends without a valid TLS closure alert.

**Explanation:** RFC 2818 Sections 2.2 and 2.2.1 separate three decisions: whether the HTTP message is complete, whether earlier protected data remains trustworthy, and whether the TLS session may be reused. A: Selected. Section 2.2.1 gives this as the exception for a request whose declared amount of data arrived. B: Selected. Section 2.2 prohibits reuse after a premature close even if the application can identify a complete message. C: Selected. The document says the concern is possible truncation of subsequent data, not automatic compromise of data already received. D: Not selected. A missing closure alert is the defining difference between premature and authenticated closure. E: Not selected. HTTP completeness does not remove the TLS session-reuse prohibition.

Q10: What guarantee is still missing after successful HTTPS validation?

Multiple Choice

An agent receives an unsigned discovery message containing https://attacker.example/card. It fetches the URL over TLS; the certificate validly identifies attacker.example. The fetched Card claims authority over a protected A2A service.

**Explanation:** RFC 2818 Section 3.1 warns that endpoint checking does not protect against a compromised source of the URI. Here TLS proves that the client reached the endpoint named by the attacker-selected URI; it does not authorize that endpoint's claims about another service. A: This confuses authentication of the selected endpoint with authorization of the party that selected it. B: Token audience and Card authority are separate claims; neither is created by a matching HTTPS certificate. C: Correct. The application needs a trust rule for who may introduce or sign metadata for the protected service. D: Port selection does not repair the missing provenance and authority binding.