Network protocol: NPN and ALPN in encrypted transmission

Introduction

Since HTTP was upgraded from 1.1 to 2, everything has changed. Although HTTP2 does not mandate that encryption protocols must be used for transmission, industry standards, including popular browsers, only support the HTTP2 protocol in the case of HTTPS.

So how to add support for HTTP2 protocol to HTTPS? Today this article will talk to you about the NPN and ALPN extensions of the SSL/TLS protocol.

SSL/TLS protocol

SSL (Secure Socket Layer) is a set of protocols designed by Netscape in 1994, and version 3.0 was released in 1995.

TLS (Transport Layer Security) is a protocol designed by IETF on the basis of SSL3.0, which is actually equivalent to the subsequent version of SSL.

SSL/TLS is a cryptographic communication framework, which is the most widely used cryptographic communication method in the world.

TLS is mainly divided into two layers. The bottom layer is the TLS record protocol, which is mainly responsible for encrypting messages using symmetric ciphers.

The upper layer is the TLS handshake protocol, which is mainly divided into four parts: handshake protocol, password specification change protocol and application data protocol.

One of the most important is the handshake protocol, through the interaction between the client and the server, and sharing some necessary information to generate a shared key and interactive certificate.

Next, we will introduce the meaning of each step step by step:

1. client hello

   The client sends a client hello message to the server, which contains the following content:

   • Available version number
   • current time
   • Client random number
   • Session id
   • List of available cipher suites
   • List of available compression methods

We mentioned earlier that TLS is actually a set of encryption frameworks, some of which can actually be replaced. Here, the available version number, the list of available cipher suites, and the list of available compression methods are to ask the server which services the other party supports.

The client random number is a random number generated by the client to generate a symmetric key.

2. server hello

   After the server receives the client hello message, it will return a server hello message to the client, which contains the following content:

   • Version number used
   • current time
   • Server random number
   • Session id
   • Cipher suite used
   • Compression method used

The version number used, the cipher suite used, and the compression method used are the answers to step 1.

The server random number is a random number generated by the server to generate a symmetric key.

3. Optional step: certificate

   The server sends its own certificate list. Because the certificate may have a hierarchical structure, in addition to processing the server's own certificate, it also needs to send the certificate signed for the server.
   The client will verify the server's certificate. If communicating in an anonymous way, no certificate is required.

4. Optional step: ServerKeyExchange

   If the certificate information in the third step is insufficient, ServerKeyExchange can be sent to build an encrypted channel.

   The content of ServerKeyExchange may include two forms:

   • If the RSA protocol is selected, then the parameters (E, N) for RSA to construct a public key cipher are passed. Let us recall the formula for constructing the public key in RSA: $ciphertext=plaintext^E\ mod\ N$, as long as we know E and N, then we know the public key of RSA, and the two numbers passed here are E and N . For specific content, please refer to RSA algorithm detailed
   • If the Diff-Hellman key exchange protocol is selected, then the key exchange parameters are passed. For details, please refer to more secure key generation method Diffie-Hellman

5. Optional step: CertificateRequest

   If it is in a restricted-access environment, such as fabric, the server also needs to request a certificate from the client.
   If client authentication is not required, this step is not required.

6. server hello done
   The server sends a server hello done message to tell the client that its message is over.

7. Optional step: Certificate

   In response to step 5, the client sends the client certificate to the server

8. ClientKeyExchange

   There are still two situations:

   • In the case of public key or RSA mode, the client will generate a preliminary master password based on the random number generated by the client and the random number generated by the server, encrypt it with the public key, and send it back to the server.
   • If the Diff-Hellman key exchange protocol is used, the client will send its own party to generate the Diff-Hellman key and need to disclose the value. For details, please refer to more secure key generation method Diffie-Hellman , so that the server can calculate the preliminary master password based on this public value.

9. Optional step: CertificateVerify

   The client proves to the server that it is the holder of the client certificate.

10. ChangeCipherSpec (Ready to switch password)

    ChangeCipherSpec is a message of the password specification change protocol, indicating that the following messages will be encrypted with the previously negotiated key.

11. finished (end of handshake agreement)

    The client tells the server that the handshake protocol is over.

12. ChangeCipherSpec (Ready to switch password)

    The server tells the client to switch the password.

13. finished (end of handshake agreement)

    The server tells the client that the handshake protocol is over.

14. Switch to application data protocol

    After this, the server and the client communicate in an encrypted manner.

NPN and ALPN

When we introduced the SSL/TLS protocol above, the last step was to switch to the application data protocol. How did the client and the server discuss which application data protocol to use? Is it using HTTP 1.1? Or HTTP2? Or SPDY?

The TLS extension protocol will be used here. NPN (Next Protocol Negotiation) and ALPN (Application Layer Protocol Negotiation) are two extension protocols of TLS.

They are mainly used in TLS to negotiate what application data protocol the client and server should use to communicate.

Among them, NPN is an extension used by SPDY, and ALPN is an extension used by HTTP2.

What is the difference between the two of them?

Compared with NPN, ALPN has already listed the application layer protocols supported by the client in the client hello message, and the server only needs to select the protocols it supports. One less interactive step than NPN, so ALPN is the recommended protocol.

The following is the specific interaction flow chart:

Interactive example

Let's take ALPN as an example to explain the specific interaction process. First, the client sends a "Client Hello" message:

    Handshake Type: Client Hello (1)
    Length: 141
    Version: TLS 1.2 (0x0303)
    Random: dd67b5943e5efd0740519f38071008b59efbd68ab3114587...
    Session ID Length: 0
    Cipher Suites Length: 10
    Cipher Suites (5 suites)
    Compression Methods Length: 1
    Compression Methods (1 method)
    Extensions Length: 90
    [other extensions omitted]
    Extension: application_layer_protocol_negotiation (len=14)
        Type: application_layer_protocol_negotiation (16)
        Length: 14
        ALPN Extension Length: 12
        ALPN Protocol
            ALPN string length: 2
            ALPN Next Protocol: h2
            ALPN string length: 8
            ALPN Next Protocol: http/1.1

You can see that in the Extension field in the client hello message, ALPN is used, and two ALPN Protocols that can be used are listed: h2 and http/1.1.

The corresponding "server hello" message will select the specific ALPN protocol used as follows:

    Handshake Type: Server Hello (2)
    Length: 94
    Version: TLS 1.2 (0x0303)
    Random: 44e447964d7e8a7d3b404c4748423f02345241dcc9c7e332...
    Session ID Length: 32
    Session ID: 7667476d1d698d0a90caa1d9a449be814b89a0b52f470e2d...
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
    Compression Method: null (0)
    Extensions Length: 22
    [other extensions omitted]
    Extension: application_layer_protocol_negotiation (len=5)
        Type: application_layer_protocol_negotiation (16)
        Length: 5
        ALPN Extension Length: 3
        ALPN Protocol
            ALPN string length: 2
            ALPN Next Protocol: h2

As shown above, the server has selected h2, and finally when the TLS handshake between the client and the server ends, it will choose to use HTTP2 as the subsequent application layer data protocol.

Summarize

Both NPN and ALPN are extensions of TLS. In comparison, ALPN is easier to use.

This article has been included in http://www.flydean.com/08-ssl-tls-npn-alpn/

The most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don't know are waiting for you to discover!

Welcome to pay attention to my official account: "Program those things", know technology, know you better!