How does ALPN work?

How ALPN fits into the TLS handshake

ALPN is part of TLS negotiation, so the client proposes one or more application protocols and the server chooses the protocol it will actually speak before encrypted application data begins. That makes ALPN a control-point for protocol selection, not a separate security layer. The important operational question is whether the negotiated protocol matches what the service is meant to expose.

In practice, ALPN helps a single endpoint support multiple application protocols on the same port, which is why it is common with HTTP/2 and HTTP/1.1. The server advertises what it accepts, the client sends its preference order, and the handshake settles the result early enough for both sides to use the right framing and semantics once encryption starts.

What can go wrong when protocol negotiation is wrong

If the client and server do not agree on a shared protocol, the connection may fail, fall back, or behave in ways that are hard to diagnose. A mismatch can look like a transport problem, but the root cause is often that one side offered only the wrong protocol set, or an intermediary altered what the client or server believed was available.

Downgrade concerns matter because the negotiated protocol affects how securely and efficiently the service operates. If a stronger protocol was expected but a weaker one is selected, defenders should treat that as an integrity and service-design issue, not just a compatibility nuisance. Confirming the expected protocol set is especially important when proxies, load balancers, or termination points sit between the client and the origin service.

For protocol negotiation to be trustworthy, the endpoint configuration must be deliberate. If a system unexpectedly advertises legacy protocols, accepts more options than intended, or fails to negotiate the expected protocol at all, the resulting behaviour can expose service inconsistencies, bypass assumptions in application logic, or obscure whether the user reached the intended backend.

How to verify ALPN behaviour in real services

Verification starts with the service boundary, not the application code. Check which protocols the endpoint advertises, which one the server actually selects, and whether that selection is stable across direct connections and proxied paths. Then compare the observed result with the service design, because the right answer is often environment-specific rather than universal.

It is also useful to confirm how clients behave when their preferred protocol is unavailable. Some clients will gracefully negotiate an alternative, while others will fail closed. That difference matters during rollout, because a protocol migration can appear safe in testing but still break production traffic when a real client population includes older implementations or strict policy settings.

Where ALPN is used with HTTPS, the negotiation result should be visible in logs, traces, or packet captures at the TLS handshake stage. That evidence helps distinguish a certificate problem, a cipher-suite issue, and a protocol-selection problem, which are often conflated during incident triage.

Risk and Threat Considerations

ALPN itself is not the attack surface, but it can expose weak protocol governance and create downgrade or misrouting conditions if the advertised and selected protocols do not match the intended service design. In a proxy-heavy architecture, the main risk is that a trusted control plane makes the wrong protocol decision and the failure only appears as an application outage or unexpected fallback.

Failure mechanism: A client, server, or intermediary negotiates an unintended protocol, or the service advertises a broader set of protocols than policy allows, leading to downgrade, mismatch, or broken session establishment.

Impact: The service may become unavailable, operate with weaker protocol properties than expected, or route traffic into a backend path that was not meant to handle that application behaviour.

Practitioner Guidance

What to verify: Treat ALPN as a configuration assurance check. Validate the exact protocol list exposed by each listener, compare it with the expected production profile, and confirm that proxies and TLS-terminating intermediaries preserve the intended negotiation outcome.

Decision rule: If a service can negotiate a weaker or legacy protocol than policy intends, fix the advertised protocol set before tuning client behaviour. If the mismatch only appears behind a proxy or load balancer, investigate the intermediary first, because that is often where the effective protocol choice is being changed.

Practitioner takeaway: ALPN is most useful when it is boring and predictable, so the real control objective is not just successful negotiation, but consistent negotiation of the right protocol across every path that can terminate or relay TLS.

Related resources from NHI Mgmt Group

• What is an SVID and how does it work?
• How does OAuth 2.0 work for NHIs and what are its limitations?
• What is identity spoofing in Agentic AI and how does it work?
• When should teams prioritise NHI governance over other IAM work?