Are you familiar with the concept of ALPN? If not, don't worry - you're not alone. ALPN, or Application-Layer Protocol Negotiation, is a relatively new protocol that is rapidly gaining popularity in the world of web development. In this blog post, we will explain what ALPN is, how it works, and why it's important.
What is ALPN?
ALPN, or Application-Layer Protocol Negotiation, is a TLS extension that includes the protocol negotiation within the exchange of hello messages. ALPN is able to negotiate which protocol should be handled over a secure connection in a way that is more efficient and avoids additional round trips. In simpler terms, it's a way for a client and a server to agree on a protocol that they both support, and then use that protocol to communicate. The HTTP/2 protocol, makes use of ALPN to further decrease website load times and encrypt connections faster.
How does a TLS handshake work?
In order to fully understand the benefits of using the ALPN extension, the process of how a TLS handshake works should first be explained. According to the RFC 5246 specification, TLS involves the following steps:
- The client and server exchange hello messages to agree on algorithms, exchange random values, and check for session resumption.
- An exchange of the necessary cryptographic parameters allow the client and server to agree on a premaster secret.
- A master secret is generated from the premaster secret and exchanged random values.
- Security parameters are provided to the record layer.
- The client and server verify that their peer has calculated the same security parameters and that the handshake took place without tampering by an attacker.
This handshake process is the equivalent of two round-trips from the client to the server and back. The more round trips incurred, the longer the latency times will be and the longer a user must wait to receive information from the server.
The number of round trips is largely due to the handshakes to start communicating between client and server (e.g. DNS, TCP, HTTP)... If we can improve protocols to transfer this data with fewer round trips, we should also be able to improve page load times.
- Mike Belshe, More Bandwidth Doesn't Matter (Much)
How does ALPN work?
According to the RFC 7301 specification, with ALPN the client will send a list of supported application protocols to the server as part of the TLS ClientHello message. The server then selects a protocol and sends back that protocol in its ServerHello message. The application protocol negotiation can therefore be accomplished over one single round trip within the TLS handshake. This method also allows the server to associate a different certificate with each application protocol.
To visually demonstrate, an abbreviated ALPN handshake looks similar to the following diagram.
As we can see, the list of support protocols is sent to the server upon the first message thus minimizing the amount of round trips necessary.
Why is ALPN important?
ALPN is important because it allows for better performance and security in web communications. By negotiating which application-layer protocol to use, the client and server can choose the protocol that is best suited for the data being transmitted. For example, if the data being transmitted is text-heavy, HTTP/2 may be the best protocol to use because it supports server push and header compression, which can reduce latency and improve performance.
In addition to improving performance, ALPN also improves security. By specifying which application-layer protocol to use, ALPN can ensure that the client and server are using the most secure protocol available. For example, HTTP/1.1 is susceptible to certain types of attacks, such as slowloris attacks, that are not possible with HTTP/2. By negotiating the use of HTTP/2, ALPN can help protect against these types of attacks.
ALPN also enables the use of new application-layer protocols. Without ALPN, it would be difficult to introduce new protocols because there would be no way for the client and server to negotiate which protocol to use. ALPN allows for new protocols to be introduced and adopted more quickly, which can lead to better performance and security.
NPN vs ALPN
NPN, or Next Protocol Negotiation, is the predecessor of ALPN and was widely used in conjunction with SPDY. NPN had some security and performance issues, which led to its deprecation in favor of ALPN. NPN is quite similar to ALPN. However, the main difference is that NPN does not include the list of supported protocols in its ClientHello message. The NPN extension is included in the ClientHello message. However, it is the server which sends back the list of protocols for the client to choose from.
ALPN, on the other hand, reverses this process. Thus the ClientHello message includes the list of supported protocols for the server to choose from. This change was made to help further align ALPN with other protocol negotiation standards. ALPN is also advantageous for reverse proxies as they are able to begin the resource selection process immediately after receiving the ClientHello message. Additionally, ALPN offers better performance by reducing the latency of the negotiation process. Overall, while NPN was useful in its time, ALPN is a more secure and efficient protocol for negotiating application-layer protocols in web communications.
The move towards ALPN
The move towards ALPN in modern web communications is driven by its improved security, performance, and flexibility compared to the previous protocol, NPN. Its adoption by popular web servers and clients, as well as its requirement in newer web technologies, indicates its significance in the industry. As web communications continue to advance, ALPN will likely remain an important protocol for negotiating application-layer protocols securely and efficiently. With impressive speed results, to enhanced security features, all websites owners and visitors can benefit from the improvements that the ALPN extension has to offer in combination with HTTP/2.
To see if your website supports HTTP/2 and ALPN visit our HTTP/2 Test tool.