RFC 7301 Quiz

**Explanation:** **Context (why chosen):** ALPN is often described only as “needed for HTTP/2,” but the deeper skill is seeing it as a negotiation mechanism for multiplexing multiple application protocols on the same secured endpoint. **Terms:** **ALPN** stands for **Application-Layer Protocol Negotiation**. It allows protocol selection to happen inside the TLS handshake instead of after the connection is already established. **Real-world usage:** In practice this matters on port 443 where a server may support HTTP/1.1, HTTP/2, or other protocols and wants to choose quickly without another round trip. **Options:** - A (incorrect): Certificate protection is not the purpose of ALPN. - B (correct): This is the central design goal of RFC 7301. - C (incorrect): ALPN does not replace ports or DNS-based discovery. **Related:** The RFC was motivated in part by HTTP/2 over TLS, but the mechanism is general and can negotiate arbitrary application-layer protocols.

**Explanation:** **Context (why chosen):** Many implementation mistakes come from misunderstanding who proposes options and who makes the final selection. **Terms:** In **ALPN**, the client advertises supported protocol identifiers in the **ClientHello**. The server selects one supported protocol from that list. **Real-world usage:** This matters when debugging a client that thinks it offered HTTP/2 but the server still negotiated HTTP/1.1 or failed the connection. **Options:** - A (correct): The client advertises candidates rather than making the final decision. - B (incorrect): The client does not force the server to accept exactly one pre-chosen protocol. - C (incorrect): Certificate chains are not carried as ALPN candidates. **Related:** Server-side preference still matters. The server usually chooses the most preferred protocol that both sides support.

**Explanation:** **Context (why chosen):** ALPN and SNI are commonly mentioned together, so people often conflate routing by hostname with negotiating the protocol spoken after TLS comes up. **Terms:** **SNI** identifies the target server name. **ALPN** identifies the application protocol to use within the TLS-protected connection. **Real-world usage:** This distinction matters in load balancers, TLS terminators, and certificate debugging where the hostname and protocol choice influence different parts of the stack. **Options:** - A (incorrect): This mixes unrelated concepts. - B (incorrect): They are separate extensions with different purposes. - C (correct): This is the correct separation of responsibilities. **Related:** A server can use both pieces of information together, for example to route traffic and choose a certificate or protocol-specific backend behavior.

**Explanation:** **Context (why chosen):** Operationally, this is the point where “TLS succeeded but the application did not” turns into an explicit handshake failure rather than a silent mismatch. **Terms:** **no_application_protocol** is the alert used when there is no common application protocol between client and server. **Real-world usage:** This shows up when clients offer only `h2`, servers support only HTTP/1.1 over TLS, or proxies strip or mis-handle ALPN configuration. **Options:** - A (incorrect): The server must not invent a protocol the client did not advertise. - B (correct): This is the RFC-defined failure behavior. - C (incorrect): Downgrading to plaintext is not an ALPN fallback. **Related:** Clean failure is important because “pick something else and hope” produces hard-to-debug protocol mismatches and false confidence.

**Explanation:** **Context (why chosen):** People often treat ALPN as a pure compatibility feature, but the RFC also frames it as a deployment tool that can influence certificate and backend choices. **Terms:** **certificate selection** means the server may choose among possible certificates based on the negotiated application protocol. **routing behavior** can also differ by negotiated protocol. **Real-world usage:** This matters in multi-tenant ingress, TLS offload layers, and environments where protocol choice influences which backend or credential chain is appropriate. **Options:** - A (correct): This captures the design motivation described by the RFC. - B (incorrect): Clients do not upload replacement certificates through ALPN. - C (incorrect): Certificate validation remains essential. **Related:** Protocol negotiation, hostname indication, and certificate selection are distinct concerns, but real deployments often make them interact.

**Explanation:** **Context (why chosen):** ALPN is easy to think of as “just a negotiation tool,” but the RFC explicitly discusses visibility and the risk of leaking protocol choice metadata. **Terms:** An **externally visible marker** is something on-path systems may infer before application data is exchanged. ALPN protocol identifiers can become such markers depending on TLS version and deployment. **Real-world usage:** This matters when protocol identifiers themselves are sensitive, when profiling risk exists, or when network elements make differentiated-service decisions based on protocol choice. **Options:** - A (correct): The RFC warns that in earlier TLS versions the client's protocol identifiers can be visible. - B (incorrect): ALPN was not designed to hide protocol choice pre-connection. - C (correct): This is explicitly part of the RFC's design discussion. - D (incorrect): The RFC does not provide such a guarantee and instead warns about leakage risk. **Related:** If protocol secrecy matters, you need a design that truly hides the selection rather than assuming the ALPN field does that automatically.

**Explanation:** **Context (why chosen):** Engineers sometimes assume ALPN is an advisory hint. The RFC treats the server's selected protocol as binding for the connection. **Terms:** **definitive for the connection** means the selected application protocol is the one that governs application data exchange on that TLS connection. **Real-world usage:** This matters in reverse proxies and TLS terminators. If the front end reports `h2` but the backend logic speaks something else, failures become subtle and severe. **Options:** - A (incorrect): That violates the point of explicit negotiation. - B (incorrect): The selection is not limited to the first response. - C (correct): This is the intended meaning. **Related:** Protocol negotiation is useful precisely because it reduces ambiguity about what both sides should speak after the handshake completes.

**Explanation:** **Context (why chosen):** Resumption often causes incorrect mental models such as “the old session decides everything.” RFC 7301 explicitly says ALPN is a connection property, not a session property. **Terms:** A **connection property** applies to the current handshake and connection instance. ALPN is negotiated per connection, even when resumption is used. **Real-world usage:** This matters when a client resumes to the same endpoint but offers different protocol support or when server configuration has changed since the earlier connection. **Options:** - A (correct): The new handshake controls the current connection's ALPN outcome. - B (incorrect): ALPN is not pinned to the prior session in that way. - C (incorrect): There is no plaintext side negotiation replacing ALPN here. **Related:** This distinction is important because confusing session properties with connection properties leads to stale assumptions in TLS debugging.

**Explanation:** **Context (why chosen):** Real incidents often look like “TLS worked, but the wrong protocol was used.” That is usually a negotiation outcome or config mismatch, not evidence that ALPN failed to run. **Terms:** The client sends a **list** of acceptable protocols. The server selects one supported protocol. Success does not mean the most preferred client protocol was necessarily chosen. **Real-world usage:** This is a standard investigation pattern when an origin, load balancer, or CDN unexpectedly serves HTTP/1.1 instead of HTTP/2. **Options:** - A (incorrect): SNI does not force HTTP/2. - B (correct): A successful negotiation can still end on `http/1.1` if that is what the server chooses from the shared set. - C (incorrect): ALPN does not require automatic selection of the newest protocol. **Related:** Good debugging asks “what did the client offer, what did the server support, and what did the server choose,” rather than assuming success implies the fastest or newest protocol.

**Explanation:** **Context (why chosen):** The end goal of learning RFC 7301 is to reason across configuration layers, not to memorize the extension type number. **Terms:** **ALPN**, **SNI**, **certificate selection**, and **routing** solve different problems, but deployment failures often happen at their boundaries. **Real-world usage:** This is the kind of high-value comment you want in ingress reviews, proxy configuration reviews, and TLS incident postmortems. **Options:** - A (correct): This is the most operationally mature framing. - B (incorrect): SNI does not replace application-protocol negotiation. - C (incorrect): TLS success alone does not prove the negotiated application protocol is the one you intended. **Related:** Mature ALPN understanding means you can explain not only what the extension does, but also where the surrounding deployment can still go wrong.