HTTP/2 and ALPN are related in the context of secure web communications.
When a web client (like a browser) and a server communicate, they need to establish a secure connection using the TLS (Transport Layer Security) protocol if they’re using HTTPS. During this process, they also need to agree on the version of HTTP they’ll use for their communication.
In the past, with HTTP/1.1, this wasn’t a big issue. But with the introduction of HTTP/2, there was a need for a mechanism to negotiate which HTTP version should be used, without adding extra round trips and latency.
That’s where ALPN comes in. It’s an extension to the TLS protocol that allows the client and the server to agree on which protocol (HTTP/1.1, HTTP/2, or others) to use right at the start of their communication, during the TLS handshake. So, it enables the efficient use of HTTP/2 (or other protocols) over secure connections.
In summary, HTTP/2 and ALPN are related as they work together in the process of establishing a secure and efficient web communication. HTTP/2 provides the performance improvements for web communication, and ALPN enables those improvements to be efficiently negotiated and used over secure connections.
This is important. In a TLS handshake, there are indeed a ClientHello and a ServerHello, and one of the things they negotiate is the cipher suite to be used for encryption. However, that’s separate from the application protocol negotiation done by ALPN.
ALPN does involve a ClientHello and a ServerHello, but what’s being negotiated isn’t the cipher suite—it’s the application protocol (like HTTP/1.1 or HTTP/2) that will be used over the secure connection.
When talking about ALPN, remember that ALPN is a negotiation protocol for application protocols as a TLS extension. There’s a ClientHello that includes the application protocols it supports, and there’s a ServerHello that selects the application protocol it will use from that list. If you’re having issues with HTTP/2, it’s important to do a packet capture to:
A: See what cipher suite is being used, because a blacklisted cipher suite could be causing problems, and
B: Confirm that the Client and ServerHello ALPN negotiations are taking place, as problems here could also impact the use of HTTP/2.
You can check the Cipher Suite Black List:
https://datatracker.ietf.org/doc/html/rfc7540#appendix-A
#Look to see if the Cipher Suite is Black Listed#
You are making sure the Cipher Suite is supported by the product and not black listed.
Client Hello:
Transport Layer Security > TLSv1.2 Record Layer: Handshake Protocol: Client Hello > Handshake Protocol: Client Hello > Cipher Suites
Server Hello:
Transport Layer Security > TLSv1.2 Record Layer: Handshake Protocol: Client Hello > Handshake Protocol: Server Hello
#Verify that ALPN is being sent by both the Client and Server#
Good:
Bad:
You can see for the “Bad” that the server never sent ALPN. It’s either filtered on their side, they’re not using it, etc…
#Wireshark Packet Capture Filters Used#
Client Hello:
ssl.handshake.type == 1
Server Hello:
ssl.handshake.type == 2